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ABSTRACT 



This thesis demonstrates how a new software technology, hypertext, can 
provide capabilities which will improve the handling and utilization of naval 
messages on board ship. The current process for shipboard message handling 
involves the use of communications equipment, computers, duplication 
machines, and such manual operations as control, distribution, annotation, 
filing and search. An Automated Message Handling System based on the 
hypertext concept offers opportunities to enhance each of these operations. 
The enhancements will come from performing required tasks in a more orga- 
nized manner while requiring less dependence on paper and providing a far 
more efficient and effective means for using naval messages as an informa- 
tion resource. Developments in computer technology make it feasible to im- 
plement such a system on currently available, low cost, commercial hardware. 
This thesis includes a logical design for a hypertext message system devel- 
oped using rapid prototyping techniques. 
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I. INTRODUCTION 



The efficient use of information on board ship is increasingly important 
at a time when the Navy faces an expanding mission and fewer available 
resources. The capability to properly process and use information is a 
necessity given the current environment. Messages represent an especially 
vital shipboard information resource. They are the Navy’s most frequently 
used means of communication, playing a key role in the conduct of virtually 
all administrative and operational business. The value of the information 
they contain requires that adequate mechanisms and procedures exist to 
manage their handling and facilitate their use. 

The current volume of message traffic and the requirements of the users 
for processing information indicate that the present paper-based system may 
have reached the limits of its usefulness. This thesis investigates current 
trends toward the automation of shipboard information systems and provides 
a systems analysis and design for an improved message handling system. The 
proposed system is based on the principles of hypertext, a relatively new 
software technology for handling information. Hypertext offers opportunities 
to enhance user access to information while eliminating the need to distribute 
and store paper copies of messages. 

A. BACKGROUND 

The current process for shipboard message handling involves the use of 
communications equipment, computers, duplication machines, and such 
manual operations as control, distribution, annotation, filing and search. The 
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present methods used to review, store and retrieve naval messages fail to 
take advantage of currently available information technology. The processing 
and distribution of messages to end users require extensive duplication 
efforts, greatly contributing to the proliferation of paper on board ship and 
wasting numerous man-hours. Elaborate personal file systems must be 
maintained by users to guarantee their ability to access information when 
needed. These paper-based systems allow each message copy to be stored in 
only one file folder at a time. In order to locate and retrieve messages through 
a variety of different identifiers, users must file redundant copies under 
several different category headings. The present system makes no provisions 
for rapidly accessing cited references or keeping track of those messages 
requiring responses. Failure to locate such information when needed often 
results in the commission of errors that could have otherwise been avoided. 
The current system also lacks a mechanism for assisting message drafters to 
use existing information in the generation of new messages. Recent advance- 
ments in information technology provide feasible alternatives capable of 
addressing these problems. 

B. OBJECTIVES 

The Navy is already aware that computers can be used to automate the 
distribution, storage and handling of shipboard message traffic. Some auto- 
mated systems have already been developed to improve these procedures and 
others are being investigated. Most of the current emphasis on automating 
paper-based shipboard information systems has concentrated on getting rid of 
paper and replacing it with data stored in an electronic format. This helps to 
address some of the problems, but leaves many unanswered. The objective of 
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this study is to contribute to ongoing Navy efforts to improve shipboard 
message handling procedures. A systems analysis and design are presented 
for a new computer-based information system that confronts the problems 
with the current procedures and provides enhanced capabilities for processing 
and using messages. 

C. SCOPE 

The analysis and design of an improved system for handling the distri- 
bution, storage, retrieval, and use of naval messages is the focal point for this 
thesis. The mechanisms and features of hypertext are used to support the 
user requirements and design issues developed during the systems analysis. 
The concentration of the design has been on “what” the system must do to 
meet the needs of the user as opposed to “how” the system should be physi- 
cally implemented. The hardware requirements for such a system are not 
addressed. 

The design methodology utilized rapid prototyping techniques to develop 
the system features and user interface. Prototypes have been built using 
Guide and HyperCard, currently available hypertext products for IBM com- 
patible and Macintosh personal computers, and NextStep, a user interface 
and development environment for the NeXT computer. The purpose of the 
prototyping effort is to demonstrate the features and capabilities of hypertext 
as they apply to the message handling system; a complete working model of 
the system has not been developed. 
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D. ORGANIZATION OF STUDY 



1. The “Paperless” Ship Initiative 

Chapter II presents the reader with background on the “paperless” 
ship initiative, a program created in 1986 to reduce the Navy’s requirements 
for paper-based documentation aboard naval ships. This chapter identifies 
problems with the Navy’s current message handling procedures, discusses 
current automation efforts, and presents opportunities for further 
improvements. 

2. Systems Analysis and Methodology 

Chapter III provides a systems analysis for an improved message 
handling system. This chapter identifies the user requirements for the system 
and lays out a set of principles to guide the design efforts. Three alternative 
solutions for implementing the system are identified and evaluated. The use 
of rapid prototyping as a methodology for designing the system is also 
presented. 

3. The Vision and Mechanisms of Hypertext 

Chapter IV provides an in-depth discussion of hypertext, the 
method that was chosen as the best design alternative during the systems 
analysis phase. This chapter introduces the reader to the background and 
terminology of hypertext, explaining the building blocks of this technology as 
well as the more complex issues of composition and access. 

4. Automated Message Handling System Design 

Chapter V adapts the mechanisms and features of hypertext 
introduced in Chapter IV to the user requirements and design principles 
developed during the systems analysis. A logical design for the Automated 
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Message Handling System (AMHS) is presented. The design takes a func- 
tional approach, providing detailed descriptions of message receipt, distri- 
bution, review, filing and retrieval, and message generation. 

5. Conclusions and Recommendations 

The final chapter discusses the conclusions and recommendations of 
the study. The benefits of using hypertext for improving shipboard message 
handling procedures are reviewed, and recommendations for further research 
are identified. 
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II. THE “PAPERLESS” SHIP INITIATIVE 



The Navy is currently placing a great deal of emphasis on reducing the 
quantities of paper found on board its warships. In late 1986 Vice Admiral 
Joseph Metcalf III, deputy chief of naval operations for surface warfare, 
created the “paperless” ship initiative under the direction of the Space and 
Naval Warfare Systems Command. The goal of this initiative is to reduce the 
requirements for paper-based technical, reference, and mission critical 
documentation aboard naval ships. To accomplish this goal the Navy has 
directed its attention towards the storage of information in a digital format. 
Various storage media are being investigated to determine their suitability 
for the task, including optical disk technology. (Ruff, 1988, p. 157) 

There are two major motivations behind the initiative. The first is that 
paper consumes space and weight aboard ship which could be better utilized 
for the storage of additional weapons systems and ammunition. The second is 
concerned with the inordinate amount of time required by ship's officers and 
crew to manage and use the immense volumes of paper aboard ship. It is this 
second issue that is perhaps the most crucial because the time spent handling 
paper takes away from that available for the practice of “warfighting” skills. 
The Navy is aware that advances in information technology present viable 
options for reducing paper requirements and improving information 
management. 
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A- PLAN FOR ACHIEVING THE 'PAPERLESS" SHIP 



A three phase plan has been implemented to achieve a “paperless” ship 
by the early 1990's. Phase I, completed in May 1987, consisted of a data 
collection survey to establish a baseline of the volume of paper currently held 
aboard United States Naval warships. Phase II involved a shipboard 
demonstration of optical disk technology which resulted in favorable user 
feedback regarding its potential for use aboard ship. Phase III, currently in 
progress, incorporates the recommendations from Phases I and II and places 
a prototype system on four ships. (Ruff, 1988, p. 158) 

The results of the Phase I study proposed a wide range of technical and 
reference publications, messages, ship's drawings, forms, reports, and logs for 
automation. The study identified considerable weights and volumes of paper 
on all units surveyed. Surface ships were found to contain the greatest 
amounts, though significant quantities were also recorded aboard a 
submarine and at an air squadron. A newly commissioned Aegis cruiser was 
found to contain 35.9 tons of paper and associated containers and a frigate 
some 20.6 tons. (Ruff, 1988, p. 158) 

B. CATEGORIES OF PAPER 

The paper found aboard ships can be broken down into three general 
categories: reference materials, working materials, and stock material. 
Reference materials include such items as technical manuals, charts, 
engineering drawings, and operating procedures. This type of material is 
generally produced by an activity outside the ship and distributed to a large 
number of units. It is updated on an infrequent basis and the ship will typi- 
cally maintain several copies to ensure easy access. The second category, 
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working materials, are used in the performance of daily administrative and 
operational assignments. They include such items as messages, admini- 
strative files and records, and logs and record forms. This information must 
be easily accessible at all times because it is used on a daily basis and 
represents the most current and up to date data available. The third category 
is stock materials. These include the blank paper, forms, and log books which 
will be used to support the need for working materials. (Chickering, 1988, 
p. 227) 

Reference materials represented the largest portion of the information 
identified during the Phase I survey. They accounted for some fifty-five per- 
cent of the paper while the working documents and stock materials were 
recorded at twenty-five and twenty percent respectively. (MacDonald, 1987, 
p. 15) Because of these figures and the relatively static nature of reference 
materials, this category has received the greatest attention thus far as an 
area for potential reductions. 

C. AN EVALUATION OF PAPER 

Before examining alternatives for reducing the quantities of paper-based 
information on board ship it is necessary to examine the advantages and 
disadvantages of this medium. 

1. Advantages 

“One of the most beneficial traits of paper-based documentation is 
the great degree of intimacy the user is able to have with the material it con- 
tains.” Distributing information in a paper format allows the user to establish 
a personal domain over the material. This sense of ownership and control 
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results in a more effective transfer of information to the user. (Chickering 
and Qualls, 1989, p. 63) 



Another advantage deals with availability. Information stored in 
paper form is always available, without being dependent on the operation of 
additional hardware and software to retrieve it. Paper is also easily dis- 
tributed. It can be delivered or carried to any part of the ship without requir- 
ing the presence of a terminal to use it. The paper format allows a document 
to be easily customized to meet user needs. The user can take a paper 
document and make annotations in the margins and highlight portions of its 
text so that it will convey greater meaning when the information is referred 
to at a later date. (Van Dam, 1988, p. 894) 

2. Disadvantages 

There are also many disadvantages to using paper-based informa- 
tion systems, especially on board ship. The two factors that drew early 
attention from Vice Admiral Metcalf are the weight and volume of space that 
is occupied by paper. But these are by no means the extent of the problems 
with paper. 

Information stored in paper form must be indexed and filed so that 
it may be accessed at a later time. The nature of the medium requires this 
activity to be performed manually. This can be a time consuming and 
frustrating task, but one that is very important to a paper-based system. The 
accessibility of the information to the user is a direct function of how well 
these files are organized and maintained. To solve some of these access and 
timeliness problems users tend to file redundant copies under different 
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identifiers, further complicating the issue of paper proliferation. (Chickering, 
1988, pp. 227-228.) 

The paper format limits the ability of multiple users to access 
documents simultaneously. (Chickering and Qualls, 1989, p. 63) Since paper 
does not lend itself to being shared very well, an interested user will typically 
borrow the document and make a copy of his own. In any modern 
organization information is viewed as an important resource, the Navy is no 
exception. This perspective creates an environment where workers seek to 
obtain and control information. The result for many organizations, including 
the Navy, is the building of personal paper filing systems, or databases. 

In addition to the significant weight and storage space required by 
paper, this medium also presents a serious fire hazard aboard ship. The Navy 
considers fire to be the single most dangerous threat to the safety of its ships. 
Paper could easily fuel a fire and would most certainly be destroyed by any 
extinguishing efforts. Paper also tends to deteriorate. This most commonly 
occurs with age, but in the machinery filled environments on board ship it is 
not uncommon for paper materials to come in contact with water, fuel, oils, 
greases, and other substances which cause it to degrade more rapidly. The 
maintenance of paper systems is a very costly operation. Copier machines, 
toner and paper are significant operating expenses for modern warships. 
(Chickering, 1988, p. 228) Elaborate destruction methods for classified 
documents further add to the cost of paper-based systems. 
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D. MESSAGE STORAGE AND HANDLING REQUIREMENTS 

Though somewhat overshadowed by reference materials, naval messages 
make significant contributions to the volume of paper aboard ship. Current 
distribution procedures involve taking messages that are received in elec- 
tronic form, printing them, duplicating the appropriate number of copies and 
then finally routing these copies to the individual users. It is particularly 
interesting that in this age of modern computers a large portion of the Navy 
is still converting electronically transmitted messages to paper for dissemin- 
ation and use. 

The volume of messages received and distribution requirements will 
vary from ship to ship. Some of the factors that tend to influence volume 
include the size of the ship, its operating requirements, and whether or not a 
staff is embarked. Typically an aircraft carrier will receive the greatest 
number of messages of all the ships in a battle group. The ratio between the 
number of messages processed by the aircraft carrier and the smaller units is 
approximately 10:1. Table 1 presents statistics compiled for an aircraft 
carrier with embarked staff during a recent deployment to provide some 
estimates of how many messages are actually handled on board ship. 

Each message is checked against distribution lists to determine how 
many copies must be made and who will receive them. Table 2 depicts the 
distribution requirements for messages received by the staff embarked on the 
aircraft carrier. 
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TABLE 1. DAILY MESSAGE TRAFFIC VOLUMES FOR 

DEPLOYED CARRIER AND EMBARKED STAFF 



For Entire Ship 


Send 


245 




Receive 


1166 


For Staff Only 


Send 


24 




Receive 


460 



TABLE 2. STAFF MESSAGE TRAFFIC DISTRIBUTION REQUIREMENTS 





# Messages/ 


# Copies/ 


# Copies/ 


Classification 


Day 


Message 


Day 


Top Secret 


9 


1 


9 


Secret 


55 


9 


495 


Confidential 


299 


17 


5083 


Unclassified 


97 


17 


1649 


Average total number of copies for staff 




7236 



If each of these messages were only a single sheet in length, the paper 
required to duplicate the staff message traffic alone for the six month deploy- 
ment would consume 1,302,480 sheets. This is equivalent to 260.5 cases of 
copier paper which would occupy 130.25 cubic feet and weigh 5,210 pounds. 
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This paper originally exists as stock material, blank copier paper, and is 
converted to working material as messages are duplicated and distributed. 
Not all of these copies will be stored, in fact a good portion will be destroyed, 
but the current system necessitates that this paper be carried on board to 
satisfy the requirements for distributing information. 

The electronic storage of information creates opportunities to reduce 
paper requirements in favor of storage formats that would occupy far less 
space and weight. A single 5-1/4 inch diskette, of the type commonly used for 
IBM compatible personal computers, can store over 150 pages of data in one- 
tenth the space required to store the equivalent amount of information in 
paper form. Technological developments have created other forms of digital 
storage, such as high density magnetic and optical disks that are capable of 
storing even greater quantities of information in a smaller space. (Chickering, 
1988, p. 230) Figure 1 demonstrates how three different electronic storage 
formats could each handle the task of storing the number of messages 
distributed by the carrier group staff during their six month deployment. Use 
of any one of these formats could significantly reduce the need to carry such 
large quantities of stock material. The tremendous storage capabilities made 
possible by optical disk technology make it an especially attractive 
alternative. 
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Figure 1. Electronic Storage Capacities 



E. THE NEED FOR AUTOMATED MESSAGE HANDLING 

There is a clear need to develop paperless information systems to 
improve the Navy’s current methods for handling message traffic. Formal 
channels of communication have traditionally relied heavily on printed 
documents as a means of distributing information. Current volumes of 
messages and the requirements for processing information seem to indicate 
that the limits on the usefulness of paper for distributing, storing and 
retrieving information have been reached. Technological breakthroughs over 
the last several decades are raising questions concerning the importance and 
necessity of paper in the information systems of the next century. The 
solution most often suggested today is an electronic alternative to paper. 
(Lancaster, 1978, p. 1) 
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Naval messages are a prime candidate for use in an electronic format 
instead of a paper-based system. The electronic transmission of message 
traffic allows for easy capture at the destination point in a digital format. 
This provides the Navy with the opportunity to design and develop a system 
that will receive messages and distribute them in an electronic form for on- 
line review. 

1. Current Automation Efforts 

Much of the current emphasis on automating paper-based ship- 
board information systems has concentrated on getting rid of the paper and 
replacing it with data stored in an electronic format. The “paperless” ship 
initiative has shown a great deal of interest in optical storage technology as 
an alternative to paper. Research has been performed regarding the 
mastering of reference material on optical disk CD-ROM (Compact Disk - 
Read Only Memory) which then could be supplied to the ship for use. Early 
results indicate that optical disks offer a practical alternative for the storage 
of large amounts of information in a small space. (Chickering and Qualls, 
1989, p. 61) 

Optical technology has come to the forefront because of the 
immense volumes of data that can be held on a single optical disk. However, 
not all optical disks are alike. Several different categories of optical storage 
media have been developed, all offering significant increases over removable 
magnetic disk technology. The most prominent thus far has been CD-ROM. 
Current 1989 technology enables over 550 megabytes of data to be stored on a 
single CD-ROM disk. This is the equivalent of 1500 standard 5.25" floppy 
disks, 700 Macintosh 3.5" disks, thirty 20-megabyte hard disks, or some 
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270,000 pages of printed text. This format allows a user to access information 
from a previously mastered disk, but does not permit any information to be 
added to or removed from the disk. WORM (Write Once Read Many) is 
another form of optical disk which permits the user to write to and read from 
the disk but not to erase any of the information once it is stored. The WORM 
disk is presently capable of holding either 200 or 400 megabytes, depending 
on whether or not information is stored on a single side or on both sides. 
(Zilber, 1988, p. 158) 

The latest introduction to the family of optical storage devices is the 
magneto-optical disk. This format is a significant breakthrough for mass 
storage technology because it offers full read/write/erase functionality in a 
high density removable disk. This technology was introduced in the late part 
of 1988 as part of the NeXT computer. The capacity of the disk is 256 
megabytes. (Webster, 1989, pp. 111-112) As was illustrated previously, two of 
these disks (currently priced at $50 apiece) would be capable of holding the 
equivalent number of pages required to distribute an embarked carrier group 
staff s traffic for six months. 

Storing documents in a digital format on high density storage media 
addresses many of the issues behind the first motivation for the “paperless” 
ship initiative — that paper consumes space and weight aboard ship which 
could be better utilized for the storage of additional weapons systems and 
ammunition. It also opens up many new possibilities for tackling the second, 
more important motivation: reducing the inordinate amount of time required 
by ship's officers and crew to manage and use the immense volumes of paper 
aboard ship. Documents stored in a digital format present users and 
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information resource managers with opportunities to redesign and improve 
the way they use information. 

2. The Present State of Automating Messages 

The Navy has made some significant efforts to improve its proce- 
dures for handling messages aboard ship. Computers are already employed 
aboard ship to assist in some of the functions required for processing message 
traffic. 

a. The NAVMACS System 

The Naval Modular Automated Communications System 
(NAVMACS) serves as the standard afloat automated telecommunications 
system, but despite the name the system is still far from being fully auto- 
mated. The purpose of the NAVMACS system is to perform the necessary 
processing required to terminate and originate a ship's General Service 
message traffic. NAVMACS is actually a family of system configurations that 
vary in age, size, and performance capabilities from ship to ship. Many of the 
older versions still utilize paper tape as the method of entry for outgoing 
messages and printed copy for delivery of incoming messages. (NAVTASC, 
1989) 

The latest, most sophisticated, version is the NAVMACS V5 
system. This version, installed only on carriers and flag configured ships, 
offers entry and delivery of messages through remotely connected display and 
printer terminals. The NAVMACS V5 can be configured with up to 16 
terminals spread throughout the ship. The system is designed to process 
message traffic, both incoming and outgoing, but is not an archive and 
retrieval device. System storage is small, consisting of two redundant disks 
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each capable of holding only 2 megabytes of data. The system is rated at 
5,000 messages per day with current usage at 3,000 messages or less. 
Messages are typically stored on the system for less than a day. They are 
then backed up to a tape system where they are maintained for a period of up 
to 60 days. (Telephone conversation, Mr. Dick Demello, SPAWARS, 22 March 
1989) This system is still essentially paper-based and offers little in the way 
of added functional benefits to the user. 

The Navy is already aware that its methods, especially on 
ships with older configurations, require extensive manpower and paper 
requirements, are error prone, and require constant supervision. Automatic 
Data Processing technologies are being examined for ways to improve the 
efficiencies of message handling operations. (NAVTASC, 1989) 
b. The Personal Computer Message Terminal 

The Personal Computer Message Terminal (PCMT) couples 
Personal Computer (PC) hardware equipment with Navy developed software 
systems to further automate message processing functions. This program is 
still in the developmental stages. The system is being proposed to interface 
with the NAVMACS system, allowing the two systems to work in tandem to 
improve afloat message handling procedures. The objective of the PCMT 
project is to develop a system that could be installed on board ship to help 
automate the NAVMACS message entry and delivery functions. (NAVTASC, 
1989) 

The PCMT will write incoming messages received from the 
NAVMACS system to disk storage and assign a message accountability 
number that can be used for transaction logging or later retrieval. The PCMT 
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will utilize the Local Routing List/Distribution Blocks passed from NAV- 
MACS to determine which users will be designated as receivers of a message. 
The system as planned would enable messages to be sent to a printer, written 
to diskette, or routed through a security device to a Office Automation System 
(OAS) or Automated Information System (AIS). The PCMT design states that 
the OAS can be operated as a stand alone workstation or as a local area 
network connecting a group of workstations. The AIS described in the PCMT 
design might involve an interface with existing systems such as SNAP. 
COMNAVTELCOM has been tasked with testing software developed by 
industry and government agencies to interface with the PCMT. (NAVTASC, 
1989) 

CINCLANTFLT is currently operating an office automation 
system to assist in the processing of narrative record communications. This is 
a shore based system which automates the distribution of messages by using 
an off-the-shelf electronic mail software package, All-In- 1. (NAVTASC, 1988, 
pp. 1-3) The CINCLANTFLT Office Automation System (COAS) has made 
significant strides towards improving the utilization of naval messages, 
c. The Defense Message System 

Another automation effort currently being pursued by the 
Defense Communications Agency (DCA) is the Defense Message System 
(DMS). A working group was formed in 1988 to assess the future of the 
Department of Defense's messaging systems. The goal of the group is to 
formulate a target architecture based on available, or reasonably achievable 
technology, that meets the requirements of transferring information from 
originator to receiver while cutting operating costs and staffing. Secondary 
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objectives include improving the system's functionality, survivability, and 
security. (DCA, 1988, p. 1-1) 

The major emphasis of DMS appears to be shore-based com- 
mands, but the efforts of this program are likely to impact future shipboard 
communication as well. The current components of the DMS are the 
Automatic Digital Network (AUTODIN) and electronic mail on the DoD 
Internet. AUTODIN is a worldwide computerized, general purpose com- 
munications system that transmits both narrative and data traffic by secure 
means. The present DoD Internet is composed of the Defense Data Network 
(DDN) and associated Local Area Networks (LANs). (DCA, 1988, p. 1-2) The 
target architecture for DMS calls for the evolution of the system to Integrated 
Services Digital Network (ISDN) compatibility to allow use of the ISDN as 
the DMS transport mechanism. (DCA, 1988, p. 2-2) 

The DMS working group has identified a list of requirements 
to guide the DoD's progress towards improving its message communication 
system. These requirements are stated in general terms to allow the services 
flexibility in developing solutions that meet their individual needs. Many of 
the requirements deal with the delivery of information from the originator to 
the receiver, but DMS also begins to address how to improve the ways in 
which information can be used at the receiving end. The DMS Target Archi- 
tecture and Implementation Strategy clearly lays out a requirement for the 
system to support the storing of messages after delivery and to provide a 
means of retrieval to allow for readdressal, retransmission, and such 
automated handling functions as archival, analysis, and incorporation of 
segments into future messages. (DCA, 1988, p. 1-6) 
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3. Opportunities for Further Improvements 

Modern technology is being applied to naval telecommunications 
with the purpose of improving current procedures for handling messages. 
Efforts thus far have concentrated on replacing the present printed media 
with an electronic format. But simply digitizing messages will do little to help 
users interface with the information. The current challenge is to develop 
systems that are capable of taking full advantage of this format, making the 
information contained in message traffic more accessible and easier to use. 

Recent computer hardware and software advances have permitted 
the development of systems which allow users to gain greater control over 
their information resources. These systems are revolutionizing the way 
people are performing their jobs, making their use of information more 
efficient and effective. The changes that are taking place may also impact the 
quality of decisions being made by providing users quicker and easier access 
to relevant data. Systems such as database, electronic mail, and hypertext 
can be used for a wide range of applications to support the information 
requirements of users. The combination of these systems with the immense 
storage capabilities of optical disks offers exciting possibilities for improving 
the utilization of information aboard ship. (Chickering and Qualls, 1989, 
p. 61) The application of information retrieval technology need not be 
restricted to reference materials but can also be applied advantageously to 
working materials such as naval messages. 
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III. SYSTEMS ANALYSIS AND METHODOLOGY 



The previous chapter identified the problems that exist with the Navy's 
paper-based system for handling message traffic and explored some opportu- 
nities for improving it. This chapter presents a systems analysis for a new 
computer-based information system that addresses the problems with the 
current procedures and provides enhanced capabilities for processing and 
using messages. 

Systems analysis is the first phase in the project development life cycle 
of new information systems. This phase typically involves surveying the situ- 
ation, studying the current system, defining user requirements and evaluat- 
ing alternatives. (Whitten, Bentley, Ho, 1986, p. 8) The problems that exist 
with paper-based information systems aboard ship and the current state of 
automating naval messages were addressed in Chapter II. These issues 
represent the survey and study phases of the analysis. The following sections 
address user requirements, design principles, application alternatives, and 
methodology. 

A. DEFINING USER REQUIREMENTS 

The objective of the proposed system is not simply to duplicate current 
message handling procedures electronically but to improve them by adding 
additional capabilities. The definition phase of systems analysis seeks to 
identify what these capabilities are without specifying the details of how they 
will be accomplished. The approach to this phase identifies the "knowledge 
workers" who will use the system, reviews the "business mission" of the 
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organization, and defines the information system functions that the new 
system must provide. (Whitten, Bentley, Ho, 1986, p. 191) 

1. Knowledge Workers 

This information system is being developed to support the users of 
message traffic aboard ship (hereafter referred to as users). This is a diverse 
group, typically consisting of all officers, chief petty officers, and selected 
members of the crew. The needs of the users will vary according to their 
assigned tasks and responsibilities. The information contained in messages is 
used for a variety of purposes, including: keeping current with ongoing 
events, providing guidance in the performance of designated duties, and 
responding to messages requesting that information be provided to another 
activity. An automated message handling system must be capable of support- 
ing these user needs and providing desired functions in a manner that 
enhances the performance and efficiency of the current manual system. 

2. Business Mission 

An important aspect of developing a new information system is to 
determine if the system helps to fulfill the business mission of the organiza- 
tion. The mission of the Department of the Navy (DON) is to be prepared to 
conduct prompt and sustained combat operations at sea in support of United 
States national interests. The DON Strategic Plan for Managing Information 
and Related Resources (IRSTRATPLAN), SECNAV INSTRUCTION 5230.10, 
identifies several information trends related to the DON mission that support 
the need for an improved shipboard message handling system. These include: 

• Information overload of both the commander and the telecommunica- 
tions facilities is continuing as a result of the implementation of modem 
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computing power and the demand for more real-time tactical, logistics, 
and intelligence information. (SECNAVINST 5230.10, 1988, Enel 1 p. 4) 

• The efficient utilization of information resources is a tactical necessity 
to the operational commander when executing an expanding mission 
with fewer resources. The ability to properly manage information can be 
the force multiplier to offset resource shortfalls. (SECNAVINST 
5230.10, 1988, Enel 1 p. 5) 

• The need to provide quality processed information to the comman- 
der/decision maker in the most useful format. (SECNAVINST 5230.10, 
1988, Enel 1 p. 14) 

• An increased demand for information, available and usable within the 
manager’s or decision maker’s work space. (SECNAVINST 5230.10, 
1988, Enel 1 p. 7) 

• A growing demand to transition from hard copy to electronic media for 
technical information. (SECNAVINST 5230.10, 1988, Enel 1 p. 7) 

• Potential to reduce the paperwork burden on both professional and 
support staff through office automation in an integrated environment. 
(SECNAVINST 5230.10, 1988, Enel 1 p. 13) 

3. Information System Functions 

The purpose of this aspect of the analysis is to determine the user's 
information requirements. The factors brought out by identifying the system’s 
users and examining the role of information in the business mission of the 
organization facilitated the identification of these requirements. It was 
determined that the improved system must provide for the distribution, stor- 
age, retrieval, and generation of messages. To accomplish this, mechanisms 
must be provided which allow the users to perform the following actions: 
a . Review Newly Received Messages 

Messages are received on a continuous basis by the ship's 
communications center. Users will typically pick up and review the messages 
distributed to them one or more times each day. The frequency of this review 
tends to increase during underway operational periods. The proposed 
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automated system must provide users with a mechanism for scanning a list of 
messages that have been received since the last review process. This list can 
then be used as a tool for selecting messages and displaying them on the 
screen. Users can read messages displayed at local terminals and take appro- 
priate actions on them without requiring that a paper copy be distributed. 

b. Organize the Storage of Messages 

Messages that have been received and reviewed often have 
value for future reference. All messages received must be captured and stored 
by the system. Each receiver of message traffic will have their own context for 
how the message may be of use to them at a later time. The value of messages 
will vary based on their content. Some traffic may be rapidly identified as 
holding no future value, while others may be needed by the user throughout 
an entire six month deployment. Selected categories of messages may be 
required which date back years, even to the commissioning of the ship. The 
system must provide users with a mechanism for organizing and filing these 
processed messages. 

c. Retrieve and Review Previously Received Messages 
Users must be provided with access mechanisms for retrieving 

and reviewing messages that have been previously processed. This need is 
especially important for examining those documents that are cited as refer- 
ences in other messages. The message of interest may be one that was dis- 
tributed to the user and filed, or one that was received by the command and 
not distributed to user for some reason. Various access mechanisms must be 
provided to ensure that every message received can be accessed. 
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d. Annotate Messages with Comments and Highlighting 

When users read their message traffic they may want to cus- 
tomize some of the documents with comments, instructions or highlighting so 
that it conveys greater meaning or serves as a reminder during subsequent 
review. The system must provide mechanisms enabling users to perform 
these tasks. 

e. Route Messages and Annotations 

The receiver of message traffic may determine that informa- 
tion contained in messages or personalized annotations is needed by other 
users on the ship. An example of this might involve a senior informing a sub- 
ordinate about some required action that must be taken. To facilitate this 
requirement the system must provide a means for routing message material 
amongst its users. 

f. Keep Track of Action and Response Items 

Some of the messages reviewed will require a specific action to 
be taken or a response to be sent. With the large volumes of messages sent 
and received by ships, keeping track of these requirements can often become 
a difficult task. A common solution to this problem is to maintain a running 
list of all required actions and responses. The common name for this list is a 
"Tickler" file. Such files are often maintained on personal, departmental, and 
command levels. The system must provide a means for creating and main- 
taining such lists. 

g. Draft Messages and Route for Approval 

In addition to the receiving and reviewing functions, users are 
often required to initiate messages that are transmitted by the ship to other 
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commands and activities. The drafting of messages requires that users follow 
rigid format and content rules. The system will provide tools that will facili- 
tate adherence to these rules, and allow users to take full advantage of infor- 
mation contained in previously processed messages. Draft messages must 
also be routed to various officers on the ship for approval before they can be 
released for transmission. The system will provide a mechanism for routing 
electronic message drafts through the chain of command instead of paper 
ones. 

B. PRINCIPLES AND DESIGN ISSUES 

In evaluating alternative solutions and designing an automated system 
for handling shipboard message traffic, important considerations must be 
made with regard to the Navy's existing policies, both formal and informal. 
Changing any system raises certain concerns, but one as critical as an inter- 
face between the communications center and the users of message traffic 
deserves even greater attention. The fundamental issues that will be consid- 
ered include: 

1. Integrity and Security of Messages 

The single most important issue that must be considered is main- 
taining the integrity and security of the messages handled by the system. 
Naval messages are a formal means of communication. The nature of the 
information they contain requires that measures be taken to ensure that 
messages cannot be altered, lost, or destroyed by inadvertent or malicious 
means. This requires that the system provide built in security measures and 
redundant storage mechanisms. 
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2. Ease of Retrieval 

Facilities must be provided to ensure that any message received by 
the system can be quickly and easily retrieved. During the initial review 
stage users will sit down at remote terminals and call up a list of messages 
that have arrived since their last review session. The user will then select a 
message from the list to be retrieved and displayed on the screen. This pro- 
cess should be simple and fast. The time taken to retrieve the message should 
take no longer than that required to turn the pages in a stack of message 
traffic. When a user identifies a need for a previously processed message he 
must first locate or identify the message and then initiate a retrieval. The 
user may only have a limited amount of time to obtain this message so speed 
and simplicity must be considered important factors. Ease of retrieval is an 
essential ingredient for guaranteeing user acceptance of an automated 
replacement for the current system. 

3. Access 

Another key issue deals with user access to information. Here Navy 
policy firmly dictates that only those personnel having the proper security 
clearance and need for the information can have access to it. Provisions must 
be made to enforce these constraints, preventing the system from facilitating 
any unauthorized access to messages. This concern applies to subsequent 
routings in addition to initial distributions. 

4. Flexibility 

The flexibility of the system is another important issue. Though 
numerous standards and regulations exist concerning the handling of mes- 
sages, each command is likely to have specific individual requirements that 
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need to be supported. Commands must be able to control distributions and 
routings as well as the organization of information structures for the filing 
and retrieval of messages. Since users will establish personal structures for 
arranging their information, the system must be capable of reorganizing 
these structures when an individual’s needs change or a user transfers and is 
replaced by someone else. 

5. Ease of Use 

The knowledge workers for whom this system is proposed represent 
intelligent end users, but this does not imply that their sophistication can be 
an excuse for complicated commands and operating procedures. The system 
must be friendly enough to encourage use, making it easy to review messages, 
file and locate them for subsequent retrieval, and generate new ones. 

C. EVALUATION OF ALTERNATIVE SOLUTIONS 

The purpose of this phase of the systems analysis is to determine the 
best solution that will satisfy the user requirements for the new information 
system. (Whitten, Bentley, Ho, 1986, p. 191) Three computer-based alterna- 
tives were considered for improving the handling of message traffic aboard 
ship. All three involved use of digital storage media to support the trends of 
the "paperless” ship initiative. The options included existing relational 
database methods, traditional electronic mail (E-mail) systems, and a rela- 
tively new area of technology called Hypertext. 

1. Database 

Traditional database methods could be used to order and retrieve 
messages based on values in their formatted fields. The Navy's strict format- 
ting requirements make this a feasible solution. Messages could be stored and 
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uniquely identified for retrieval by their Date Time Group (DTG) and origina- 
tor. Use of the Standard Subject Identification Codes (SSICs) could provide a 
means for ordering and retrieving information based on preset subject break- 
downs. Authorization constraints specifying limitations on the types of 
actions users can perform could be used to enforce access restrictions. 
(Kroenke and Dolan, 1988, p. 249) The database approach appears sufficient 
for organizing storage in an electronic form which would reduce current 
requirements for paper. However, a traditional database solution fails to ful- 
fill some important user requirements. A database could provide for central- 
ized retrieval, but it would lack the personal context required by the system. 
The capability to maintain a personal file organization and annotate mes- 
sages without altering the originals is not easily facilitated in this environ- 
ment. The "view" feature of relational database management systems 
(RDBMS) enables the user to customize the presentation of information based 
on the record oriented data contained in the formatted fields of the message. 
While this feature provides a certain degree of flexibility to meet the chang- 
ing needs of individual users, the database approach severely limits the 
potential for dealing with the material contained in the body of the message. 
A RDBMS would treat the entire body as a single data item. Such a system 
would be useful only as a tool for displaying selected messages. Database user 
interfaces, while improving, often require the user to learn and remember a 
query language in order to gain access to the information. Current database 
systems lack the ease of use called for in the design issues. If the user's only 
concern were retrieval a database might be satisfactory, but such an 
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approach fails to address many of the user requirements and would severely 
limit the usefulness of the information stored. 

2. Electronic Mail 

Electronic mail systems provide a means for sending, receiving, 
storing, and forwarding messages in digital form. On the surface this seems 
like the perfect solution to the problem. An E-mail approach would certainly 
be able to handle the distribution and review requirements. The need for 
paper would be significantly reduced, but an E-mail system would result in 
the redundant electronic storage of messages in a similar way that paper is 
redundantly stored in the current system. This wastes large amounts of elec- 
tronic storage and creates difficult data management problems. Despite the 
fact that protection mechanisms can be employed, the presence of multiple 
electronic copies of documents raises concern over the integrity and security 
of the message, and the ability of unauthorized personnel to access it. Most E- 
mail systems lack the file organization capabilities and flexibility specified in 
the user requirements. Many systems simply provide the user with an un- 
structured "mailbox” for holding messages. Those E-mail systems that permit 
"filing" often require the user to remember specific commands for moving and 
retrieving messages. The failure of these systems to fulfill the "ease of use" 
requirements often discourages users from organizing their messages. The 
ability to annotate without altering the original message is also missing. E- 
mail is a more promising alternative than the traditional database approach, 
but it also fails to meet significant system requirements. 
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3. Hypertext 



Hypertext systems were the newest and least understood alterna- 
tive at the outset of this investigation, but it was also the one that offered the 
greatest potential for revolutionizing the usage of shipboard message traffic. 
Recent computer hardware and software advances have permitted the devel- 
opment of systems which allow electronic links to connect logically related 
pieces of information. Such systems allow the user to interact directly with 
information, giving them increased control over how the information is orga- 
nized for retrieval and review. This concept of linked documents which can be 
accessed in a nonlinear fashion is generally categorized as Hypertext. 
(Chickering and Qualls, 1989, p. 61) 

The ability of Hypertext to electronically link information, when 
applied to the Navy's shipboard message handling procedures, creates oppor- 
tunities for users to annotate and highlight important portions of messages 
without altering the original document. The user can immediately reference 
related documents, in addition to indexing and filing for later retrieval. 
Indexes and file organizations can be easily changed giving the user a great 
deal of flexibility. By distributing electronic links only a single copy of the 
original message needs to be stored. This further supports the issue of main- 
taining the security of the message. The issue of access control can be 
addressed by requiring the distribution and routing of links to be approved by 
the ship's communications center. 

While database and E-mail systems offer a more conventional and 
established solution, the unique capabilities of Hypertext resulted in its 
choice as the best alternative for designing an improved system for handling 
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messages. The system, which will be referred to as AMHS — Automated 
Message Handling System, is introduced as a potential interface between the 
communications center and the users of naval messages. AMHS could fit into 
the existing automation efforts presented in Chapter II, by filling the role of 
the Office Automation System proposed in the NAVMACS/PCMT interface 
design. 

D. METHODOLOGY 

Hypertext has been described as a hybrid that cuts across the traditional 
boundaries of computer science. (Conklin, 1987, p. 33) As an emerging tech- 
nology there is no generally accepted method for designing and building 
Hypertext systems. However, many of the principles from existing methodolo- 
gies can be successfully applied. The approach taken thus far has followed the 
early phases of the traditional systems development life cycle (SDLC). To con- 
tinue this approach into the design phase would involve such tasks as design- 
ing outputs and inputs, files and databases, terminal dialogue, methods, 
procedures and programs. The output of such a design is a detailed set of 
specifications. (Whitten, Bentley, Ho, 1986, p. 377) While appropriate for 
some systems, the rigidness of this approach often fails to keep the user 
adequately involved during the development process. The potential impact is 
that the delivered product may not fulfill user needs. 

Prototyping is an alternative approach that is gaining acceptance as a 
means for refining user requirements and designing systems. Prototyping 
combines several phases of the SDLC, consolidating the refinement of user 
requirements with the design and sometimes encompassing portions of final 
system construction. This approach emphasizes rapidly building a model of 
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the final system that can then be reviewed with the users to determine if it is 
accurate and appropriate. The process is iterative, with the model going 
through several stages of refinement until the users are satisfied that the 
system interface and functionality meet their requirements. Prototypes can 
be either paper or working models. Depending on the level of sophistication, a 
working model might evolve into the final system or simply be discarded after 
it has served to define the user requirements. (Whitten, Bentley, Ho, 1986, 
p. 384) 

Rapid prototyping was chosen as the development methodology for the 
Automated Message Handling System. Several off-the-shelf, commercially 
available products were utilized as prototyping tools. Guide, a Hypertext 
product for the personal computer, marketed by Owl International was used 
to demonstrate the application of Hypertext mechanisms to naval messages. 
Versions of this product, which run on both IBM compatible and Apple 
Macintosh machines, were utilized to illustrate the independence of the 
design from hardware configuration. The features of Apple's HyperCard were 
also examined, though only a partial prototype was developed. A prototype of 
the system's user interface was developed using NextStep, a user interface 
and development environment for the NeXT computer. 

Prior to commencing the prototyping effort a thorough review of the 
Hypertext literature was conducted. As a relatively new field of computer 
science it was very important to gain a complete overview of the subject 
before designing a system based on its principles. This approach reduced the 
potential for limiting the system design to only those features available from 
the prototyping tools. Hypertext deals with some difficult conceptual issues 
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regarding the structuring and ordering of information. The following chapter 
discusses the vision and mechanisms of Hypertext. This narrative lays the 
groundwork for introducing the design of the Automated Message Handling 
System which is presented in Chapter V. 
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IV. THE VISION AND MECHANISMS OF HYPERTEXT 



A. INTRODUCTION TO HYPERTEXT 

The term hypertext was originated by Theodore Nelson in the 1960’s to 
refer to nonlinear text systems which could be used for the creation and 
review of documents. Nelson’s vision was that text stored digitally in the 
computer could be freed from the traditional boundaries associated with 
paper and arranged into new types of units or structures. The user would 
have the flexibility to control his path through the information by making 
choices and branching to segments that interested him. (Nelson, 1967, p. 195) 
He described hypertext as 

the combination of natural-language text with the computer’s capacities 
for interactive, branching or dynamic display, when explicitly used as a 
medium. (Nelson, 1967, p. 195) 

Many authors have described this term, but there seems to be little con- 
sensus regarding its definition. Hypertext has been labeled as an environ- 
ment for interconnected writing and literature storage (Fiderio, 1988, p. 237), 
a style of building systems for information representation and management 
(Halasz, 1988, p. 836), a model based on the assumption that human idea 
processing occurs through association (Carlson, 1988, p. 94), and an approach 
to information management (Smith and Weiss, 1988, p. 816). Hypertext is all 
of these things. There is no single agreed upon definition for hypertext, yet 
the majority of authors who have written on the subject seem to have devel- 
oped a similar mental picture of what it is. 
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From the standpoint of computer science, hypertext can be viewed as a 
hybrid. It combines features from database technology, representation 
schemes, and user interface models to create a unique environment for stor- 
ing and using information. (Conklin, 1987, p. 33) Conklin in his introduction 
and survey article focuses on hypertext’s machine-supported links. He, along 
with many others who have described hypertext systems, considers links to 
be the essential distinguishing feature of hypertext from which all other 
aspects are based. Electronic linking is the capability that makes it possible 
to organize text nonlinearly. The term nonlinear refers to the ability to 
handle material without being constrained by the physical medium. The user 
determines the order to view information instead of being constrained by a 
strict sequence created by the author or designer of the system. Another fea- 
ture very common to hypertext systems is the use of windows. Windows on 
the screen display information which has been divided up into small seg- 
ments and stored as nodes in a database. There is a one to one correspon- 
dence between these windows and the database nodes. (Conklin, 1987, p. 18) 
The segments, or units, of information are connected to one another by elec- 
tronic links. Users traverse the database by selecting and following links from 
one unit to another. (Akscyn, McCracken, and Yoder, 1988, p. 820) 

A wide range of uses are envisioned for hypertext. These include systems 
for storing and distributing literary and reference information, for providing a 
collaborative environment on large group projects, and for assisting individu- 
als and small groups involved with authoring and idea processing. Despite 
the large variation among these projects, the common concept is that infor- 
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mation should be organized into networks of nodes and links. (Halasz, 1988, 
p. 840) 

Recent interest in hypertext is attributable to technical innovations 
yielding more powerful workstations, high-resolution graphic displays, 
increased networking capabilities and decreased cost of large on-line storage. 
Mechanisms have been developed which permit the user to make direct 
machine supported references from one text document to another. New inter- 
faces allow users to interact directly with these pieces of information, creating 
new relationships between them wherever they deem necessary. (Conklin, 
1987, p. 17) The release of products for personal computers such as Guide and 
HyperCard, although lacking some of the features of high priced systems 
developed for the workstation market, has sparked a greater awareness and 
interest in hypertext. (Smith and Weiss, 1988, pp. 816-817) 

B. THE HISTORY OF HYPERTEXT 

Despite all of its recent attention hypertext is not a new idea, but rather 
one that has developed from visions for improved usage of information and 
technical innovations in the field of computers. 

1. Manual Hypertext Systems 

Manual hypertext type systems have been around since long before 
the conception of modern computer systems. The familiar stack of 3 x 5 index 
cards and the handy reference book are good examples of manual hypertext 
systems that are still in use today. These early systems characterize some of 
the important attributes of hypertext systems. The concept of taking notes on 
an index card emphasizes the modularization of information. The user limits 
the contents of the card to a single fact or small grouping of facts. Cards can 
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be referenced to one another by a number or coding scheme, and they can be 
easily reorganized to reflect a new emphasis or direction. One of the difficul- 
ties with such a manual system is locating a particular piece of information 
when there are a large number of cards. Reference books, such as the dic- 
tionary and encyclopedia can also be considered hypertext documents. The 
encyclopedia is a good example because as the user reads through a particular 
section, references are made describing where to locate more information 
about related issues. This type of referencing is a key feature attributed to 
hypertext systems. (Conklin, 1987, p. 20) 

2. Bush's “Memex” 

It is interesting to note that the first automated “hypertext” system 
was envisioned before the age of computers and decades before the term 
hypertext would be used for the first time. In 1945 Vannevar Bush, science 
advisor to President Roosevelt, described a system that foreshadowed the 
development of modern day information systems. In his article “As We May 
Think,” he discusses the need to improve the methods in which information is 
recorded, stored, and consulted. Forty-four years ago he described the 
methods of transmitting and reviewing information as being generations old 
and inadequate for user needs. Bush felt that the proliferation of information 
at that time had grown far beyond people’s ability to make any real use of it. 
His foresight into the expansion of printed information caused him to suggest 
a means for storing records and ensuring that the information could be up- 
dated and extended so that it would retain its usefulness. Aware that paper 
was not a suitable means for maintaining such large volumes, he suggested 
that microfilm be used to compress information into a smaller storage format. 
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(Bush, 1945, pp. 101-108) He did not foresee digital storage mediums, such as 
magnetic and optical disks which make compression even more feasible. 

Bush identified the key difficulty in retrieving information as 
stemming from the artificiality of indexing systems. Under conventional 
means, when information is stored it is arranged either alphabetically, 
numerically or according to some other system of organization. To find infor- 
mation with such a system it must be traced through the index until it is 
located. If the proper index entry cannot be identified the user may never find 
the desired document. Bush envisioned an improved means of indexing and 
retrieval based on the functioning of the brain: 

The human mind does not work that way. It operates by association. 
With one item in its grasp, it snaps instantly to the next that is sug- 
gested by the association of thoughts, in accordance with some intricate 
web of trails carried by the cells of the brain. The speed of action, the 
intricacy of trails, the detail of mental pictures, is awe-inspiring beyond 
all else in nature. (Bush, 1945, pp. 101-108) 

He acknowledges that while we cannot possibly hope to duplicate 
the brain’s processes with a machine, there is a great deal that can be learned 
from it. He felt that man might even be able to make improvements over the 
brain in the area of permanency of information. His vision was to develop a 
mechanized system based on selection by association instead of by indexing. 
(Bush, 1945, pp. 101-108) 

Bush describes a mechanized personal library system in his article. 
He calls this system “Memex,” and describes it as a device used to store a 
user’s books, notes, and correspondence in a form so that information could be 
accessed real time with speed and flexibility. The system would give the user 
the capability to browse through existing information as well as create new 



40 



pieces. He envisioned the “Memex” as a supplement to the user’s memory. 
(Bush, 1945 pp. 101-108) 

Bush identified the most essential feature of the system to be the 
provision for tying items together. This allows any item to be selected and 
displayed automatically from another item. When a series of items are joined 
together they form a trail or document that can be reviewed. This adds great 
flexibility, since a single item can become a part of numerous trails. Other 
advantages include the fact that trails, once established, do not fade and 
trails that are of interest to others can be passed between users. (Bush, 1945, 
pp. 101-108) It is interesting to note that the implementation of Bush’s ideas 
had to wait almost twenty years before the technology advanced to the point 
where it became feasible. 

3. Early Hypertext Pioneers 

Vannevar Bush’s concepts of associative links and browsing influ- 
enced two of the early pioneers in the field of hypertext, Douglas Engelbart 
and Ted Nelson. Engelbart began work in the early 1960’s on a project called 
On-Line System (NLS) at Stanford University. His goal has been to develop 
tools for the computer that can be used to “augment native human capacities 
toward effective action.” (Engelbart, Watson, and Norton, 1973, p. 9) NLS, 
now called Augment, has evolved into an on-line work environment used for 
the storage of memos, research notes, and documentation. It has been used 
successfully for several projects at McDonnell Douglas, also serving as an 
internal communications network. Engelbart is credited with inventing the 
computer “mouse,” and creating the concept of viewing filters. Both of these 
mechanisms play an important role in successfully building hypertext 
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systems. The mouse gives systems designers an input device that is quick and 
easy to use. The user initiates actions by simply pointing and clicking on 
items, significantly reducing the cognitive overhead associated with remem- 
bering commands. The mouse is especially convenient as a tool for activating 
links, allowing the user to jump to other segments of information in the 
database. Viewing filters permit users to view a shortened version of docu- 
ments stored in the database. This gives the user greater control of the pre- 
sentation. Filters can also be applied to the file or organization structure 
enabling the database to be quickly reviewed for relevant information. 
(Fiderio, 1988, p. 238) 

Ted Nelson expanded on Bush’s concepts, envisioning an on-line 
hypertext network system containing all the world’s literary works. It was 
Nelson who was responsible for coining the term “hypertext” in 1965 to mean 
nonsequential writing. His project, Xandau, introduces some important con- 
cepts which can be universally applied to hypertext systems. He describes 
how storage space can be saved and consistency maintained by storing a 
single copy of the original document. All alterations, annotations, references 
to related information, and organizational structure of the database are then 
related to the original through links. Another contribution made by Nelson 
applies to building hypertext systems. He clearly identifies the need to make 
a strong separation between the user interface and the database server so 
that system designs do not limit themselves to a single hardware configura- 
tion. (Conklin, 1987, p. 23) 
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4. The Progress of Hypertext Development 



The development of hypertext systems has progressed in stages 
over the past several decades. The first generation of systems was based on 
mainframe architecture. Their primary focus was on text nodes, offering little 
in the way of graphics capability. Systems that are generally grouped in this 
category include NLS/Augment and ZOG. (Halasz, 1988, p. 840) 

The ZOG system is of interest to this study because it demonstrates 
that the Navy has already had some experience with hypertext systems in a 
shipboard environment. The ZOG project was developed in 1972 at Camegie- 
Mellon University as a menu-based information display system to be used by 
a large number of simultaneous users. (Conklin, 1987, p. 26) In early 1980 
Captain Richard Martin, Commissioning CO of the USS Carl Vinson con- 
tacted the team developing ZOG at Carnegie-Mellon University. He was 
interested in ZOG’s potential for managing the tremendous amounts of 
information found aboard a modern day aircraft carrier. In a joint effort 
between the group at Carnegie-Mellon and the Navy, a distributed version of 
ZOG was developed and installed on the USS Carl Vinson. (Akscyn and 
McCracken, 1985, p. 901) 

The sheer size and number of people on an aircraft carrier creates a 
complex information management situation. The ZOG system targets middle 
and upper level management as its users. (Yoder, McCracken, and Akscyn, 
1985, p. 907) ZOG was designed to provide rapid responses to users’ selec- 
tions for information contained in a large network-structured database. The 
ZOG system refers to nodes as frames. These frames are structured in such a 
way as to support a variety of applications. (Akscyn and McCracken, 1985, 
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p. 901) Over 40 application programs have been created to run on the ZOG/ 
Vinson system supporting the following ship’s functions (Yoder, McCracken, 
and Akscyn, 1985, p. 908): 

• Representing management information about tasks and task assign- 
ments (used to produce schedules for management activities). 

• Training in weapons and aircraft elevator operation and maintenance 
(done from an on-line maintenance manual with an interface to a 
videodisk player). 

• Interface to AirPlan, a rule based expert system which assists 
decision-making for the launch and recovery of ship’s aircraft. 

• On-line policy manual (Ship’s Organization and Regulation Manual). 

This early version of hypertext has shown that hypertext can be 
adapted to a wide range of naval applications, reducing dependence on paper- 
based systems, and improving information utilization. 

The second generation systems began in the early 1980’s and are 
best described as workstation-based, research-oriented tools. Systems that fit 
into this category include Xerox PARC’s NoteCards, Brown University’s 
Intermedia, and KMS, a commercial system developed from the first genera- 
tion ZOG system. These products are very similar in concept to the first gen- 
eration systems, but the workstation technology on which they have been 
implemented allows for a more sophisticated user interface. Another distin- 
guishing feature of these systems is support for graphics and even animation 
nodes. The second generation also makes heavy use of graphic overviews of 
the network structure to assist users in navigating through the network and 
accessing information. (Halasz, 1988, p. 840) 
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The progress of hypertext over the last several years has been 
marked by the introduction of systems for personal computers. These prod- 
ucts have done much to popularize hypertext, and while more limited in scope 
and functionality than their workstation-based predecessors they do share 
many of the same features. The one critical feature not yet incorporated is the 
ability to generate a graphical overview of the network structure that can be 
used for browsing through the database. Examples of personal computer 
products include Guide by OWL International which is available for both IBM 
compatible machines and Apple’s Macintosh, Hyperties developed at the 
University of Maryland and currently being marketed by Cognetics Corpor- 
ation, and Apple’s HyperCard. (Halasz, 1988, p. 840) 

C. HYPERTEXT MECHANISMS AND FEATURES 

Although individual products tend to vary somewhat in their character- 
istics, it is possible to describe the features and mechanisms commonly asso- 
ciated with hypertext in a generic context. This discussion introduces the 
building blocks of hypertext, nodes and links, and explains how these tools 
can be used to construct more complex information structures. Various means 
of accessing information in a hypertext system are also addressed. The termi- 
nology and concepts introduced here will be used in describing the logical 
design for the Automated Message Handling System presented in Chapter V. 

1. Nodes 

In order to maximize the flexibility and usefulness offered by hyper- 
text, information is organized into small units consisting of a single concept 
or idea and stored in a database. These units are commonly referred to as 
nodes. Specific products tend to refer to nodes using a variety of different 
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labels, such as “card” in Xerox’s NoteCards and Apple’s HyperCard, and 
“frames” in KMS. Since small segments can usually be scanned faster than 
large ones, this organization allows users to rapidly browse through the 
database. Limiting the scope of the material contained in a node also allows 
for a more specific and practical organization of the information. Navy mes- 
sages are generally written to convey information about a particular subject 
in a concise form. The characteristics of navy messages make them a natural 
unit of organization for information in a hypertext system. 

Segments of information are presented independently, each in its 
own window. (Chickering and Qualls, 1989, p. 67) While some systems make 
an effort to limit the size of a node to the amount of information that can be 
displayed on the screen at the same time, it is becoming more common for 
programs to allow somewhat longer nodes to be created using scrolling fields. 
(Fiderio, 1988, p. 238) Hypertext systems typically permit the user to reposi- 
tion, resize, close, or put these windows aside as small reminder icons. 
(Conklin, 1987, p. 19) This permits users to focus on certain pieces of informa- 
tion by expanding and placing them in prominent screen locations while other 
items are displayed in smaller windows or as icons around the periphery. The 
window display format helps users manage the screen workspace more 
effectively. 

2. Links 

The nodes in the hypertext database are interconnected by links. 
Units of information that are related to each other in some way are electroni- 
cally linked together, enabling the database to be viewed as a logical network 
of nodes. (Chickering and Qualls, 1989, p. 67) These nodes may contain link 
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icons representing pointers to other segments of information in the hypertext 
database. Activating the link causes the system to jump to the referenced 
node. The desired information is then presented on the screen in a new win- 
dow that is created for it. Figure 2 illustrates a group of Navy messages 
linked to each other to form a network. 




Figure 2. A Network of Navy Messages 



Electronic links have been described as “the most distinguishing 
characteristic of hypertext.” (Conklin, 1987, p. 33) An understanding of their 
properties and capabilities is essential to any discussion of hypertext. 
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Links are the mode of movement in a hypertext network. Physically 
this key mechanism is little more than an electronic pointer but conceptually 
it is more like an electronic footnote, directing the reader to associated text 
just as a footnote directs readers of printed material to related areas of 
research. (Fiderio, 1988, p. 239) Links may be either unidi recti on al or bidirec- 
tional. Bidirectional links may be traversed from either end, permitting users 
to proceed to increasingly greater or lesser levels of detail depending on their 
needs. (Shneiderman and Kearsley, 1989, p. 3) 
a. Qualities and Uses of Links 

There are several important qualities that links must possess 
in order to perform their function in a hypertext system. One of the obvious 
qualities is that the system running the application must be capable of follow- 
ing them. They must also be able to quickly move the user from one node to 
another. (Fiderio, 1988, p. 239) Activation of a link should be simple and fast. 
If retrieving and displaying the new document takes too long then the user 
will become frustrated with the system and stop using it. When a retrieval 
from secondary storage must be made, some type of visual cue should indicate 
to the user that the request is being processed. (Conklin, 1987, p. 33) 

Hypertext systems can utilize the properties of electronic links 
to accomplish a variety of functions. These include (Conklin, 1987, p. 33) and 
(Shneiderman and Kearsley, 1989, p. 3): 

• Connecting a reference document to a given document. 

• Connecting comments or annotations to documents. 

• Providing information about organizational relationships between 
documents. 
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• Connecting pieces of information in sequence. 

• Connecting brief descriptions to documents that offer more detailed 
information. 

• Displaying an overview: index, table of contents, or browser. 

• Transferring to a new topic (subject area). 

• Activating another program. 

b. Reference Versus Organizational Links 

Hypertext documents can be linked together using two broad 
methods: reference and organization. The reference method does not impose 
any hierarchy on the structure of the document. Referential links are used to 
connect points or regions in a document to another node containing informa- 
tion. (Conklin, 1987, pp. 33-34) This is the type of link that would be used to 
connect comments, annotations, or references to a document. Organizational 
links are similar to reference links in that they are used to make connections 
between points in hypertext. However, the difference comes from the struc- 
turing of a hierarchy on the information. The concept of organizational links 
is based on the parent-child relationship or the IsA structure of semantic 
networks. Figure 3 illustrates this relationship. These types of links will often 
be employed from a mechanism displaying the organizational structure of the 
information, as opposed to being included in individual information nodes like 
the referential links. Examples of such mechanisms include graphical repre- 
sentations and the familiar table of contents. (Conklin, 1987, pp. 33-34) 
Hierarchical structures allow information to be organized and searched in an 
orderly manner, with each layer providing increased level of detail. 
(Shneiderman and Kearsley, 1989, pp. 4-5) 
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Figure 3. Organizational Links 



c. Typed Links 

Links may be typed or named to describe how they behave and 
what kind of information is located at the destination. The Guide product 
from OWL International offers a good example of typed links. Guide has three 
different types of links: Expansion, Note, and Reference links. Expansion 
links can be used to replace a selected item. The replacement can be textual 
information or a graphic. The concept behind expansion in a hypertext system 
is that clicking on a selected item can reveal increasing levels of detail about 
a particular subject while remaining in the same document. At the highest 
levels these details are hidden from the user to present a clear overall picture 
without confusing the issue with details. As the document is expanded all 
additional details are presented in context to facilitate user understanding. 
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Figure 4 illustrates the use of this type of link to expand the level of detail in 
a table of contents type structure. Selecting Main Engines in the window on 
the left hand side of the figure will result in an expansion showing the list of 
subheadings presented on the right hand side. 



BEFORE SELECTION AFTER SELECTION 



Main Propulsion 




Main Propulsion 


Fiiebox 




Fiiebox 


1. Main Engines (LM2500) 




1. Main Engines (LM2500) 


2. Bleed Air System 




A. Components 


3. Generators (Allison 501 k17) 




B. Operating Procedures 


4. Reduction Gear and Shafting 




C. Inspection Guideiines 






D. Safety 






2. Bleed Air System 




3. Generators (Allison 501 k 1 7) 




4. Reduction Gear and Shafting 



Figure 4. Expansion Links 



Note links can be used to present information about a particu- 
lar selection in a pop up window on the screen. This type of link provides the 
user with a convenient means to annotate documents with comments or 
instructions. Figure 5 illustrates a note link implemented using Guide to 
attach a comment to a naval message. 
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Figure 5. Note Links 



Activating a reference link displays the destination document 
in a new window on the screen. Reference links, as their name implies, are 
well suited for creating a path between documents and their cross-references. 
Figure 6 illustrates the use of this type of link to establish a connection 
between a naval message and its cited reference. 
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Figure 6. Reference Links 



Links can exist as graphical buttons outside the text or may be 
embedded as words or phrases in the text of the document. Guide uses font 
styles to distinguish between the different link types. When the cursor is 
positioned over a link it appears as a link icon corresponding to the type of 
link represented. The font styles and icons serve as visual cues to assist the 
user in the selection of actions. 

In the majority of hypertext systems links are “anchored” by an 
icon at a specific location in the source card, but “anchored to the destination 
card as a whole.” Clicking the mouse on the link icon traverses the link, 
retrieving the destination node and displaying it on the screen. (Halasz, 1988, 
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pp. 837-838) The fact that nodes are relatively small in size minimizes any 
confusion that may arise concerning what segment of the destination node is 
of interest to the user. The referenced node can be quickly scanned to locate 
the related information. 

3. Composition Mechanisms 

Nodes and links are the fundamental building blocks of hypertext. 
These mechanisms enable users to store information in a database and 
connect logically related pieces together. Some systems allow users to extend 
this idea by developing their own information structures for organizing 
information. These systems permit users to modify and add information or 
restructure its organization by creating, editing and linking nodes. These 
capabilities represent significant advances for information management, 
overcoming many of the restrictions that exist with traditional linear 
documents. (Chickering and Qualls, 1989, p. 67) 

Links can be used to connect multiple nodes forming group or clus- 
ter links. Uses for such a mechanism include connecting multiple annotations 
to a document, and creating specialized organizational structures (Conklin, 
1987, p. 35) The Xerox NoteCards product has defined two very useful mech- 
anisms for dealing with groups of nodes and links: “head cards” and 
“fileboxes.” 

a. “ Head Cards” 

The “head card” serves an important conceptual function by 
allowing groups or clusters of nodes to be referred to as a single unit. This 
mechanism is commonly used in NoteCards to implement higher levels of 
organization using existing mechanisms. Figure 7 illustrates how the head 
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card concept could be employed by a user desiring to personalize a message 
with some notes and comments. Application of this mechanism to the 
Automated Message Handling System will be demonstrated in Chapter V. 




Figure 7. The “Head Card” Composition Concept 



Unfortunately some problems exist with the head card concept. 
Current systems lack an adequate means for displaying and treating the 
cluster as a single unit. They can either display the head card, which does not 
show any of the links into or out of the component cards, or show all of the 
cards in the cluster in a normal manner, which fails to emphasize the group- 
ing. (Halasz, 1988, pp. 843-844) Despite this representation problem the head 
card composition concept remains a useful tool for designing and building 
hypertext systems. 
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b. “Fileboxes” 



Another mechanism that can be built from the fundamental 
node and link constructs is the “filebox.” This mechanism is based on the 
familiar mental model of a file cabinet. Just like the traditional office tool, the 
hypertext filebox provides a means for organizing information so that the 
user may easily access it at a later time. One of the more common means of 
using the filebox arrangement is to organize information hierarchically. 
(Halasz, 1988, pp. 841-842) The advantage of using such a construct in a 
hypertext system is that the file organization is accomplished through use of 
links. This means that a document can be accessed from a variety of “files” or 
identifiers while only requiring that a single physical copy be maintained in 
the database. This feature greatly improves the chances of locating desired 
information when needed without requiring the redundant storage that 
would be required in a traditional system. Such redundancies could require 
significant storage even if documents were stored electronically. The elements 
of the filebox may be represented as a graph, tree or simple list with each 
item serving as a link to the information. (Halasz, 1988, pp. 841-842) Figure 8 
shows a graphical representation of a filebox for the engineering department 
of a ship. At the lowest levels nodes would represent the head card for a 
particular message. 
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Figure 8. “Filebox” 



Xerox PARC’s NoteCards makes heavy use of the filebox con- 
struct. NoteCards requires that every notecard in the system, including file- 
boxes, be indexed or labeled in at least one filebox. This ensures that the user 
will always have some means to locate and retrieve information stored in the 
database. There is however one major flaw with the current implementation 
of fileboxes. This mechanism fails to take into consideration the difference 
between reference and inclusion relations. Fileboxes are typically imple- 
mented using the well established reference link. In the example shown in 
Figure 8 filing a Reduction Gear message would involve establishing a refer- 
ence link from the message to a head card grouping of messages dealing with 
that subject. That head card would then be connected by another reference 
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link to the topic label “Reduction Gear.” The user is given the impression of 
“filing in a filebox” connoting an inclusion relationship, but instead of being 
“included” messages are actually stored and accessed as references. The 
differences between user perception and system implementation is a potential 
source of problems if the user becomes confused about how to use the filebox. 
(Halasz, 1988, pp. 843-844). Such difficulties can be minimized by designing 
the system interface in such a way that the user does not have to worry about 
the differences between reference and inclusion relationships. 

The problem of composition has been addressed by Frank 
Halasz, one of the developers of NoteCards, as a critical issue for the next 
generation of hypertext systems. He foresees the solution to be the addition of 
composition as a basic construct in the hypertext model. This would involve 
an inclusion relation separate and distinct from the current reference link. 
Such a mechanism would solve the current problems that exist with imple- 
menting the head card and filebox concepts using reference links. (Halasz, 
1988, p. 844) 

4. Information Access 

The entire purpose of the mechanisms introduced up to this point is 
to provide an improved and more natural way for locating, retrieving, and 
using information. Hypertext allows the information stored as nodes in the 
database to be accessed in a variety of ways. As a user reviews a document he 
may decide to activate links and examine references. By following such links 
the user can wind through the database until a sufficient level of detail is 
reached. A graphical representation of the database may be used as an aide to 
navigating the network. Such representations are referred to as browsers. 
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Another method might entail the use of an index, while a somewhat more 
traditional approach to locating information may involve performing a 
database search/query for a specific keyword, phrase, or value. (Conklin, 
1987, p. 19) 

a. Navigation 

Hypertext systems are designed to allow users to skim 
through, or rapidly pursue, related pieces of information. (Fiderio, 1988, 
p. 239) This method of browsing and exploring a database is based on asso- 
ciation and is significantly different from the traditional systems which 
access rigidly formatted data records based on the contents of specified fields, 
keywords, or other identifiers. (Shneiderman and Kearsley, 1989, p. 10) 
Navigation is a characteristic feature of hypertext, but it can also cause prob- 
lems in large databases where it becomes easy for users to forget how or why 
they arrived at their present location. Hypertext’s freedom to explore may 
result in a distraction from the intended goal of answering a specific question 
or locating a specific document. (Shneiderman and Kearsley, 1989, p. 10) A 
“graphical browser” node containing a structural diagram of a network of 
nodes can be used to reduce this problem. (Fiderio, 1988, p. 239) The layout of 
the network in a browser provides contextual and spatial cues which help to 
amplify the user’s mental model of database. This results in a better under- 
standing of how nodes are related, improving the user’s ability to quickly 
locate desired information. (Conklin, 1987, p. 19) This mechanism can be 
used for orientation purposes or to help users decide on their next action. 
(Fiderio, 1988, p. 240) The diagrams presented in the browser are generated 
for the user by the system. The nodes shown in the browser are actually icons 
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for traversing links between the browser and the reference document. 
(Halasz, 1988, pp. 837-838) This mechanism allows the user to immediately 
access information by clicking on an item of interest without having to issue a 
separate command. Figure 9 provides a good example of how most browsers 
are structured. This mechanism is built using the organizational type links 
that were discussed previously to illustrate the ordering of information in a 
hierarchy. 




Figure 9. Graphical Browser 
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Another interesting means of navigating the hypertext net- 
work involves the following of predefined paths through nodes in the 
database. Conklin, in his introduction and survey article, discusses the con- 
cept of paths originally developed by Randall Trigg in his PhD dissertation on 
hypertext. Paths constitute an ordered trail that can be used to browse nodes. 
They relieve users from having to make decisions at each link, and in essence 
provide the user with a preset way through the network. Users can also be 
provided with the capability to browse the database and save the trail 
followed as a path that can be used again later, or passed to a colleague. 
(Conklin, 1987, p. 24) This can be a very useful tool in reducing the time and 
effort required to find information. 
b. Indexing 

While navigation is the primary means of access in a hypertext 
system, indexing also provides important capabilities. Indexing can be 
thought of as another means of ordering information so that the user can 
locate and retrieve items of interest. Nodes in the database may be indexed 
alphabetically, numerically, or organized hierarchically. Examples of a hier- 
archy include table of contents or outlines which represent an organizational 
structure of the database. The nonlinear nature of hypertext provides the 
potential for a variety of indexes, each describing an alternate organization 
for the information. (Shneiderman and Kearsley, 1989, pp. 11-12) An item 
could be listed in any number of indexes while still only requiring that a 
single copy exist in the database. 

Indexes can be built manually by the author or user of a sys- 
tem as well as automatically by a text parsing program. Indexes can be based 
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on the use of either a controlled or uncontrolled vocabulary. A controlled 
vocabulary implies that each document is classified by one or more entries 
from a specified list of terms. The nature of the application or the characteris- 
tics of the organization may determine the vocabulary to be employed, or it 
may be up to the user to create an individual index. The difficulty with such a 
system is that a suitable vocabulary must be created so that each node is 
classified by at least one term. Additionally the index must have a relatively 
uniform distribution of classification terms among all the nodes to ensure its 
usefulness as an access mechanism. (Frisse, 1988, p. 250) 

Another powerful document-indexing technique is classifica- 
tion with an uncontrolled vocabulary. This method can be used when a con- 
trolled list of index terms is not available. With an uncontrolled vocabulary, 
inverted indexes are created by eliminating “stop” words (the, are, a) and 
removing suffixes (-s, -ing, -ed). The remaining word roots are retained in an 
index file, which in general will be about one half the size of the original text 
file. Many who favor this approach argue that it is an effective way to retrieve 
information. This form of indexing is currently being used by a variety of 
applications for the retrieval of information from optical storage media. 
However, in many cases the amount of storage needed to maintain the 
indexes and the problems caused by misspellings and synonyms outweigh the 
benefits of this method. (Frisse, 1988, p. 250) While an uncontrolled vocabu- 
lary index guarantees comprehensive access it may result in overwhelming 
responses which are time consuming to review, further reducing its 
advantages. (Shneiderman and Kearsley, 1989, pp. 11-12) 
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The nature of the information stored in the database will 
determine its ability to be indexed hierarchically. If the database consists of 
numerous unrelated nodes then the hypertext system is essentially just a 
container for grouping the documents. If on the other hand nodes share a 
highly structured relationship with each other, retrieval techniques, such as a 
hierarchical index, can be exploited to gain true benefits from the hypertext 
interface. (Frisse, 1988, p. 250) 

A multi-level hierarchical organization is a common mecha- 
nism for structuring a hypertext database. In such a hierarchy, the top levels 
function as an index to the database. As the structure descends further down 
into the database, levels representing individual documents are revealed. The 
user can augment the hierarchy by creating links to cross-references and 
annotations. (Akscyn, McCracken, and Yoder, 1988, p. 822) Such a mecha- 
nism enables the user to locate information by scanning a category structure 
that becomes increasingly more specific at the lower levels. The user can 
visually scan the hierarchical index and then move directly to areas of the 
information network that are likely to contain the desired information. 
(Halasz, 1988, pp. 841-842) 

c. Search/Query 

Hypertext has become synonymous with navigational access. 
The ability to browse networks by following links is a characteristic feature of 
hypertext. However, the experience of hypertext developers with several 
existing systems, such as NoteCards, suggests that navigation is not suffi- 
cient by itself as an access mechanism. (Halasz, 1988, p. 841) Browsing and 
indexing are both based on the concepts of association, but they will only 
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work for previously defined links. A more traditional keyword search mecha- 
nism is often needed in addition to these capabilities. (Shneiderman and 
Kearsley, 1989, p. 12) 

Halasz identifies two classes of search/query mechanisms that 
are needed in a hypertext system: content search and structure search. A con- 
tent search considers all nodes and links in a network as separate entities; 
each is individually examined for a match to the given query. This type of 
search ignores the structure of the hypertext network. The structure search 
on the other hand examines the organizational structure for subnetworks 
that match a given pattern. (Halasz, 1988, p. 842) This would be a useful 
technique in limiting the scope of the search and increasing the probability of 
retrieving the desired information. 

In addition to their use for locating information, queries can 
also be used as a filtering mechanism. A user’s description of interest items 
would be used by the interface to display aspects of the network that matched 
the query. Irrelevant information would not be displayed. (Halasz, 1988, 
p. 843) 

d. Limitations of Access Methods 

An important aspect of understanding any system is the ability 
to recognize its limitations. There are situations where each of these means of 
information retrieval in a hypertext system is inadequate. Navigating or 
browsing through the database becomes a long and arduous process if there 
are many nodes to examine. Use of a table of contents, browser or some other 
form of indexing and presentation mechanisms fails when a node can be filed 
under any one of several categories, requiring a search of several categories to 
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find desired information. Pattern matching or search/query fails if the desired 
node uses a synonym or if the search identifies a large number of unwanted 
cards. (Frisse, 1988, p. 249) No single access mechanism is sufficient by itself, 
but by providing three different mechanisms hypertext offers users a better 
opportunity for efficiently locating needed information. 
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V. AUTOMATED MESSAGE HANDLING SYSTEM DESIGN 



The vision and mechanisms of hypertext illustrated in the previous 
chapter provide the building blocks for designing the Automated Message 
Handling System (AMHS). The objective of this design is to show how hyper- 
text can be used to fulfill the user requirements and satisfy the design princi- 
ples that were developed during the systems analysis phase. This design 
seeks to contribute to ongoing efforts to improve the Navy’s communications 
systems. 

The discussion of the “paperless” ship introduced some of the Navy’s cur- 
rent automation efforts. The Navy is aw r are that current systems are labor in- 
tensive and error prone. It is also aware that information technology offers a 
wide range of potential solutions for improving the efficiency and effective- 
ness of message handling procedures aboard ship. The Navy is presently 
investigating a personal computer interface to the Naval Modular Automated 
Communications System (NAVMACS) which would improve information 
exchange between the communications center and the end user. This system 
is called the Personal Computer Message Terminal (PCMT). While addressing 
some of the requirements for improved message handling, PCMT is primarily 
envisioned as a means for transferring messages between the commu- 
nications center and the user community through a standard diskette format 
or via a network. Additional message handling capabilities are to be 
addressed by Office Automation Systems (OAS). An OAS standard or design 
has not yet been selected. The design for the AMHS presented in this chapter 
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can be adapted to fit current Navy efforts by filling the role of the OAS pro- 
posed in the NAVMACS/PCMT interface design, or serving as a direct inter- 



face between NAVMACS and the end users of message traffic. 

The data flow diagram presented in Figure 10 provides a foundation for 
describing the features of the AMHS. This model was developed from an 
analysis of the current shipboard procedures and the information require- 
ments of the users for an improved message handling system. 

The model depicts the information tasks and flows of data that are 
involved with processing messages from their initial receipt to use. This is a 
high level presentation designed to give a global overview of the entire sys- 
tem. Although it is common to model systems independently of the mecha- 
nisms that will be used to implement them, this diagram takes into account 
the electronic linking capabilities of hypertext to emphasize the point that 
only a single physical copy of the message will be required by the system. The 
primary functions that will be discussed include message receipt, distribu- 
tion, review, filing and retrieval, tracking action items and message genera- 
tion and routing. 



A. MESSAGE RECEIPT 

The AMHS wall be used to electronically capture and store transmitted 
messages as they are received by the ship. The receipt of the message is 
acknowledged by entering its identification data into a transaction log. The 
message is then stored as a text file on a high-density digital storage device. 
The mostly likely candidate for such a storage medium is an optical disk. A 
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Figure 10. A Model for the Management and Use of Naval Messages 
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WORM drive would offer capabilities for large storage volumes and also pro- 
vide physical protection against tampering with the message. Conceptually 
the messages will be represented as nodes in the hypertext database. Figure 
11 illustrates the receipt process and shows how AMHS could serve as an 
extension of the PCMT system, or as a direct link to NAYMACS. 




Figure 11. Message Receipt 



In addition to capturing and storing messages, the receipt process will 
also examine messages and automatically create links to formally cited refer- 
ences. The format of naval messages allows for the easy identification of 
specified references on incoming messages. A text parsing program can be 
used to create an electronic reference link from the line citing the DTG of the 
reference in the incoming message to the referenced message held in the 
database. If the reference cannot be located, a note stating this fact will be 
attached as the destination of the reference link and sent as notification to 
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the communications center personnel. The communications center can then 
take the necessary action to receive a copy of the reference message. 

B. MESSAGE DISTRIBUTION 

A dissemination system is needed to ensure that incoming messages are 
properly directed to those personnel or offices requiring this information to 
perform their jobs. Much of this activity is currently handled by human 
personnel using local operating procedures to determine who will receive 
incoming messages. Those ships having NAVMACS VI, V2, or V3 configur- 
ations will append an operator specified Local Routing List (LRL) to the 
bottom of the first page of each message received. The assigned operator is 
responsible for checking the contents of each incoming message against the 
distribution lists contained in their operating procedures. The operator 
annotates the LRL to indicate who will receive a copy of the particular 
message. The NAVMACS V5/V5A reduces some of the manual effort by 
assigning actual office code distribution and copy counts based on the sys- 
tem’s data base. Each message is then duplicated for distribution and slotted 
in boxes for pickup by the users. (NAVTASC, 1989) High precedence and 
secret traffic receive special treatment and are disseminated more rapidly. 

These dissemination procedures, combined with the large volume of 
incoming traffic and the need for the user to keep informed about a wide vari- 
ety of activities, typically result in a large number of messages being directed 
to users each day. It is critical that users be able to examine this “daily 
traffic” and respond to it. Many of the items delivered will be inconsequential 
and can be processed immediately. Other items, however, may require the 
user to carry out specific actions, answer certain questions, or submit a 
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repord. Some messages issue procedural guidance that may remain in effect 
until a revision is made to formal operating instructions, publications or 
procedures. 

AMHS will accomplish the dissemination of messages to users by match- 
ing user interest profiles and security classifications against the text of 
incoming messages. Data available from the NAVMACS system can be used 
to support this process. The system will be capable of distributing a large por- 
tion of these messages automatically, based on the profiles stored on distribu- 
tion lists. Standard recurring messages will always be delivered to the same 
individuals or offices. For example, Propulsion Plant Class Advisory messages 
would always be delivered to the engineering department. It is not necessary 
for human operators to become involved with messages that can be handled 
in this manner. 

Many of the remaining messages can have assignments suggested by the 
computer and validated by a human operator responsible for monitoring the 
system. These suggestions can be made by comparing the text of the message 
against a list of SSICs, text words or phrases, and originators combined by 
boolean OR, AND, and NOT operators. After a tentative assignment list has 
been generated by the computer it is checked by the human operator who 
then has the opportunity to approve, add to, or modify the distribution. 

Once a requirement for distribution has been determined the AMHS 
must “deliver” the message to the user. This delivery consists of providing the 
user with an electronic “message link.” It is important to reemphasize that 
one of the distinguishing features of using hypertext for this system is that 
the actual message is stored only once. Unlike an electronic mail system that 
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distributes an “electronic copy” to each user’s box, the hypertext system 
distributes links. These message links serve as pointers to the message files 
that are stored in the central database. Receipt of a message link is equiva- 
lent to receiving a virtual copy of the message. Users will not be able to 
distinguish the difference between this system and electronic mail, but the 
subtlety of its implementation using links is critical to supporting the 
functional requirements and design principles that were established in 
Chapter III. The illusion of having a personal copy of the message allows 
users to think of the system in familiar terms. They will be able to access, 
customize, and organize messages just as if personal paper or electronic 
copies had been distributed. The fact that the system is implemented using 
links allows these actions to be accomplished and also supports the design 
principles of maintaining message integrity, controlling access, ensuring ease 
of retrieval, and providing flexibility. These issues would be far more difficult 
to handle in an environment where multiple copies existed. Message links are 
sent to individual user “In-Boxes” which serve as a mechanism for grouping 
links to newly received messages. The In-Box functions as the user’s means 
for accessing and reviewing daily message traffic. 

C. MESSAGE REVIEW 

Terminals will be located throughout the ship and networked to a 
central server in the ship’s communications center (remote terminals will be 
capable of serving as alternate server sites). Authorized users may access the 
system from any terminal by entering their appropriate password. After log- 
on, users may decide to review their message traffic by selecting the “Message 
In-Box” and scanning the list of message Date Time Groups (DTGs) and 
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system. Figure 12 illustrates the format for this mechanism. The Message In- 
Box is presented as a single window on the screen. This window contains two 
views in addition to a series of command buttons that can be activated to 
perform additional functions. The upper view contains the list of messages to 
be reviewed, while the lower portion includes an area for displaying one of the 
messages selected from the Message In-Box list. A button located between the 
views will allow the size of the views to be adjusted. During initial presenta- 
tion of the In-Box list the upper view will be expanded, dedicating a large 
portion of the window to the list of messages to be reviewed. When the user 
selects a particular message from the In-Box list it will be presented in the 
lower view. This view can then be enlarged to focus the user’s attention on 
the specific message selected. The AMHS offers the user additional capabili- 
ties over simply presenting the message on the screen for review, including 
accessing cited references, adding notes and comments, and inserting high- 
lights. Other features such as electronic filing, tracking action items and gen- 
erating new messages are also available from this window but will be 
described in subsequent sections since they can also be invoked as indepen- 
dent functions. 

1. Cross-Referencing 

It is very common for naval messages to reference previously 
received messages, instructions, or documents. During the review process it is 
often helpful for users to have easy access to these cited references. The 
current manual system lacks a consistent means for accomplishing this. 




Figure 12. Message In-Box 



Under the present system the user’s ability to locate a reference 
depends on a variety of factors; these include: did the user receive a copy of 
the reference; if a copy was received, was it retained; and if so, under what 
category was it filed. The current paper-based system fails to provide a rapid 
method for accessing references, and offers little assurance that they wall be 
located at all. 
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AMHS is able to greatly improve the process by supplying the user 
with electronic links to cited references. These links are automatically gener- 
ated by the system during the message receipt process. During the review 
phase, all the listed references of a message will appear as link icons. If the 
user has the appropriate access, activating the link will generate a new 
window on the screen containing the reference. This capability allows the 
user to see both a message and its references on the screen at the same time. 
If the user has not been granted access to a reference, permission to receive it 
must be requested from the communications center. 

2. Annotation 

Chapter II addressed some of the advantages and disadvantages of 
paper-based information systems. One of the advantages discussed was the 
freedom of the reader to make comments in the margins, highlight portions of 
the text, underline sections, crease pages, attach post-it notes, or in some 
other meaningful way customize the paper document. Users often feel com- 
fortable with their own customized edition, but become confused and disori- 
ented when trying to locate information in a document that has been marked 
by someone else. (Bernstein, 1988, p. 41) 

The ability to annotate messages is an important requirement of 
the AMHS. Hypertext provides powerful capabilities for fulfilling this specifi- 
cation. While reviewing a message a user can call up an electronic notepad in 
a separate window on the screen. Comments or instructions can be entered 
into a scrolling text field on the note, which can then be attached to any 
portion of text in the message that is selected. This anchor for the note may 
be a single word or phrase that triggers the user’s attention to look for 
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amplifying information. These notes may serve as keys or reminders to the 
user who created them or they may serve to answer questions or give 
instructions to other users. (Shneiderman and Kearsley, 1989, p. 41) Annota- 
tions will not appear until the user selects them. Thus if the user wants to see 
the plain text of a message as it was originally received, this view can easily 
be presented. If the user wants to see notes they can be displayed by the 
simply clicking the mouse over the appropriate link. 

3. Highlighting 

The concept of electronically highlighting a document is exactly the 
same as the manual procedure that takes place when a highlighter or marker 
is used to set off portions of printed text having greater relevance than 
others. The objective of highlighting is to save the user time when reviewing 
messages at a later date. Highlighting immediately calls the users attention 
to marked portions of the text. Highlighting will be accomplished during the 
review process by selecting contiguous portions of text that are of special 
significance to the user. After the text has been selected the user activates a 
button at the top of the window designating the selected area for highlight- 
ing. It is a simple problem for the system to obtain the starting and ending 
position for selected strings and build these locations into a file. 

When the message is called up at a later time the user will be noti- 
fied that the message being viewed has been highlighted. This can be accom- 
plished by enabling a button labeled “Show Highlights.” When a button is 
enabled it will appear dark to the user, if disabled it will appear shaded. The 
user then has the option to view the message with the highlighting applied. 
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Selecting the “Snow Highlights” button activates a program to reverse the 
video for the designated positions in the message being viewed. 

D. THE MESSAGE DOCUMENT CONCEPT 

Thus far messages have been viewed as nodes in a central database that 
can be accessed by users through electronic links. Now that the user’s capa- 
bilities to reference related messages and personalize messages by adding 
annotations and highlights have been discussed it is possible to introduce a 
slightly more sophisticated image of the system. In order to provide for these 
advanced features without requiring the system to maintain redundant 
copies of the message, it is necessary to employ the mechanisms of composi- 
tion introduced in the previous chapter. 

In Chapter IV the concept of using a “head card” for grouping collections 
of related nodes and treating them as a single entity was discussed. This 
concept can be adapted to the AMHS to help explain how users are able to 
customize their information without altering the original message. AMHS 
will refer to the mechanism used to achieve this as a “Message Document.” 
The message document concept implies that cross-references, annotations, 
and highlighting are implicitly tied to the message. In order to ensure the 
integrity of received messages in an electronic system, annotations and high- 
lights will be stored as separate nodes in the database and linked at a 
personal level to the user’s message document. The original message will 
remain unaltered. Figure 13 illustrates the message document concept. 
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The message document concept helps explain the issue of providing a 
personal context through which users can access and use the hypertext net- 
work. Each user’s context consists of a base layer that is the public hypertext 
network. In the Automated Message Handling System the public network 
will contain all of the messages processed by the command. Individual users 
will only have access to a portion of these messages. Users may access any 
message that they have received a link to from the communications center. If 
they have not received a link to a particular item that interests them, they 
must make a request to the communications center before being able to 
access it. The purpose of this restriction is to support the principle of access 
that was developed during the systems analysis. Stacked on top of this base 
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layer are personal layers. These layers are maintained by the user to provide 
a more personalized view of the information. The first personal layer consists 
of the message documents. This enables each user who receives a link to a 
message to create his own context for using the information it contains. 
Through the message document users may access a message’s cited refer- 
ences (if they have the appropriate access) as well as any personalized notes 
and highlighting they may have added. Annotations routed from other users 
can also be added to the receiver’s personal context. Figure 14 illustrates the 
idea of private contexts. This concept can be extended to include additional 
layers, further personalizing the users information domain. The message 
document and private context ideas will assist the reader of this thesis to 
visualize the underlying organization of the system. 
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Figure 14. Private Context 
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E. FINDING INFORMATION: MESSAGE FILING AND RETRIEVAL 

Many of the messages received have little or no long term value to the 
user and may not be worth retaining. Other messages may be extremely 
important to keep track of for future reference. With the current system the 
users maintain personal or office filing systems for storing these messages 
along with any relevant comments and annotations. It is the user’s responsi- 
bility to determine the appropriate indexing title or codes to file the messages 
under. These personal or office files represent one of the user’s most valuable 
and important information resources. Such files are constantly referred to 
when planning operations, operating/repairing equipment, submitting reports 
or performing a variety of other activities. 

As introduced in Chapter II these paper copy files are widespread 
throughout the ship. Often the same message will be replicated in multiple 
files of a single user as well as in several different users’ files. These files 
occupy space and represent a tremendous duplication of effort. Although no 
statistics were available for the quantity of message copies filed aboard ship, 
it is not uncommon for each of the ship’s departments to have one or more 
filing cabinets worth of messages. The number of shipboard messages filed is 
substantial and requires appropriate management. 

1. Personal Versus Centralized Filing 

The major advantage of personal paper copy files is that their 
organization reflects the viewpoint of the user. These files only contain those 
items that the user considers important, making it faster and easier to locate 
and retrieve needed material. All material in a personal file system will have 
been reviewed at least once by the user. A central computer-based file system 
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on the other hand offers the following advantages (Lancaster, 1978, 
pp. 23-24): 

• More comprehensive than personal files. 

• Can provide multiple access points conveniently and economically. 

• Economical use of space. 

• Consistency and continuity assured. 

• Nonduplicative (only filed once). 

The problem with a centralized computer filing system is that it is a 
compromise. A general system does not reflect the specialized interests of 
individual users. There is no such thing as a “typical” user, each has different 
needs and these needs are best reflected by a system that can be personalized 
to some degree. It is doubtful that a central system will eliminate the need for 
personal files, nor is it likely that highly developed personal systems could 
remove the need for an effective central system. 

What is needed is some way to incorporate the personal system 
together with the centralized one. The goal of AMHS is to provide a system 
where information is stored only once, but can be organized in a variety of 
different ways to meet the needs of a large group of diverse users. Improving 
the organization will allow for a more effective means of locating and 
retrieving information. Combining the personalized files with a centralized 
computer-based system will also reduce the volume of space occupied by these 
duplicative personal files. 

The AMHS provides the capability for building personal files using 
the “filebox” composition mechanism introduced in Chapter IV. The filebox 
can be built by creating a hierarchical organization and then moving 
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messages into appropriate categories during the review process. An example 
of such a hierarchical organization might be a subject breakdown that starts 
with very general labels and becomes increasing specific with each level, with 
the lowest levels representing links to message documents. Links to message 
documents can be filed under multiple topic headings or fileboxes to facilitate 
access, and since the links are simply pointers they will not waste valuable 
storage space by keeping multiple copies of entire messages. Figure 15 pre- 
sents an example of a filebox for the main propulsion division of a ship’s 
engineering department. 
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Figure 15. Filebox Organization 
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This sample filebox illustrates how a hierarchy can be unfolded to 
show lower levels. Such a feature can be implemented using a typed expan- 
sion link similar to the one that was discussed for the Guide product in 
Chapter IV. The third level entries in this hierarchy represent reference links 
that will display a listing of the messages filed under this heading when 
selected. Each message displayed in this list serves as a link to the user’s 
message document for that particular message. 

The concept of personalized filing provides another layer that can 
be added to the concept of private context. This layer, situated above the mes- 
sage document, allows users to customize their organizational view of the 
information. Figure 16 presents a more complete illustration of private 
contexts. 



User A 




User B 


Personal Layer II 
In-Box, Filebox, 
Tickler 




Personal Layer II 
In-Box, Filebox, 
Tickler 


Personal Layer 1 
Message Documents: 
Links to message, 
notes, highlights 


Personal Layer 1 
Message Documents: 
Links to message, 
notes, highlights 


Base Layer: Messages 



Figure 16. Two Levels of Private Context 
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2. Automatic Indexing 

On-line indexing can be utilized to automate a portion of the mes- 
sage filing process. The user will establish the categories desired for indexing 
purposes. When a user calls up one of these indexes it will already have links 
to received messages for the categories specified. This is especially useful for 
the formatted field information of the message and may include such cate- 
gories as message Date Time Group (DTG), subject, and Standard Subject 
Identification Code (SSIC). For each incoming message these fields will be 
appropriately placed in the index allowing the user to examine, for instance, a 
SSIC listing of his messages ordered by DTG. If a particular entry is of inter- 
est, the user can choose to follow a link directly to the message itself. More 
personal filing categories can be created to improve user association with the 
retrieval tags. Personalized user profiles can be created that would be com- 
pared against the context of the message to suggest filing alternatives. 
However, if the user has only a small number of categories he may choose to 
select the destination file(s) manually. 

3. Message Disposal 

A user may determine that a particular message distributed to his 
account is of no further interest and can be removed from the In-Box or 
organizational structure of the filebox. This “removal” will be accomplished by 
transferring the message link from its current location in the structure to a 
file organization in the filebox called the “Circular File.” AMHS will not per- 
mit the user to actually discard links. There are several reasons for requiring 
the system to maintain some form of link to the message instead of breaking 
all ties to it. One rationale is that the existence of the link proves the message 
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was delivered to and reviewed by the user. Secondly, if the user determines 
the message is needed at a later date, he can search through the Circular-File 
to retrieve it, narrowing the scope of the search to messages that were dis- 
tributed to the user instead of searching the entire central database. 

4. Central Index 

In addition to the user’s personalized file organization, all messages 
processed by the ship will be indexed into a central system so that a com- 
mand level view of the information is available. The centralized index system 
serves as a transaction log for all transmitted and received messages. With 
this system it will be possible to locate and retrieve every message received or 
transmitted by the ship. Users can sort the central index on a variety of iden- 
tifiers to obtain a listing that fits their needs, for example ordering by SSICs 
to easily obtain subject category listings. The access points created for the 
centralized index will differ from those in personal files in that they are 
available as public access points. Use of the centralized index will not be 
restricted, but the ability to retrieve and display messages will continue to be 
controlled by the communications center. 

5. Information Access 

As was mentioned in Chapter IV, information access through index 
and filing structures is not always sufficient for locating information in the 
database. The designers of most hypertext systems have acknowledged this 
fact and are addressing it by providing facilities for database search and 
query. The AMHS will also require such facilities. The search requirements 
for this system will need to be slightly more sophisticated than those that 
were observed in the Guide and HyperCard products. Guide’s search 
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capabilities are limited to the contents of the current document, and cannot 
search across links. HyperCard is slightly more powerful, but is limited to 
searching the cards (nodes) in the current stack (a composition mechanism 
used to tie cards together). These qualities severely limit the effectiveness of 
the search. Such a mechanism could be used to search through a pre- 
established index, but would not help to locate an item in the database using 
non-indexed specifications. 

The search mechanisms for AMHS must be capable of traversing 
links from message document nodes as well as the organizational links pre- 
sent in the personal filebox arrangements. This would allow a search to be 
initiated at a high level in the filebox structure and reveal items of interest 
that were located several levels deep in the hierarchy. Similarly if a message 
document was searched and the information in question was located in an 
“attached” note, it would also be uncovered. By giving the users the capability 
to limit the search area to a particular filebox, or a subheading within the 
filebox, inquiries will be faster and have a greater probability of locating the 
documents that really interest the user. There may be times, however, where 
the user is unable to locate the desired message in his personal filing system. 
In this situation he may examine the central index if he knows some detailed 
information about the message such as its DTG or SSIC. If this information is 
not available a global search of the entire database using a keyword or phrase 
may be required to locate the message. 

6. Message Archival 

While message traffic represents a very valuable information 
resource, its worth does tend to decline over time. This does not mean that 
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the information received will never be needed again, but that the probability 
for its use will decrease with age. This does not reduce the Navy’s need to 
adopt an improved system for handling messages, because the simple fact 
remains that when an old message is needed nobody wants to hear excuses 
for why it cannot be located. One way to handle older messages without 
losing access to them is to archive messages to successively less accessible 
storage medium on the basis of their age and activity. Though speed of 
retrieval will decrease, an interested user will still be able to access the 
message. 

F. TICKLER FILE 

Another user requirement of the system is the tracking of messages 
requiring some action to be taken or a response to be sent. The notion of keep- 
ing a file of such items, often referred to as a “tickler file", is by no means a 
new idea, but the automation of message distribution and review offers 
potential for improving the effectiveness of this tool. The tickler file will be 
implemented in a similar fashion to the filing system. The tickler file will 
serve as a composition mechanism for grouping action or response messages. 
When a message is presented on the screen during initial review from the In- 
Box or during subsequent review from the filebox the user will be presented 
with the option of opening the tickler file. This window will present, in tabu- 
lar form, a list of the DTG, action required, and due date for the 
action/response messages. Selecting a message from the In-Box or filebox and 
moving it into the tickler file will automatically enter the message DTG and 
make it a reference link to the particular message document. The user can 
then fill in the action required and the due date. During another session the 
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user may decide to examine the tickler and evaluate the status of action 
items. The link between the entries in this table and the message documents 
in the hypertext database enables the user to immediately review the mes- 
sage along with any associated notes and highlighting. Individual and 
departmental tickler files can be combined to provide the commanding officer 
and executive officer with a unit wide report. A current listing of action mes- 
sages can be of tremendous value to a command in terms of prioritizing work 
and reviewing commitments. The tickler provides a mechanism for accessing 
this information as a normal part of the message review process. 

G. MESSAGE GENERATION AND ROUTING 

AMHS will facilitate message generation by providing the user with 
templates that can be filled in with the appropriate information. A generic 
message blank as well as ones tailored for formatted messages such as 
training reports, casualty reports, and unit reports will be stored as nodes in 
the database. This, in and of itself, is not a significant improvement since 
paper format blanks already exist and some automation efforts such as 
NAVMACS, PCMT, and a product called MGS2 developed by NARDAC 
Norfolk are targeting on-line message preparation. These automation efforts 
will reduce labor requirements by eliminating the need for communications 
personnel to type messages from handwritten drafts before they can be 
transmitted. However, these efforts do not address the need of the majority of 
users who like to look at an example message when drafting a new one. They 
may have an automated terminal at which to draft a message, but they will 
still have a folder of paper messages by their side to refer to. The real advan- 
tage offered by hypertext in this area is the capability to call up a previously 
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processed message and have it displayed in a window on the screen at the 
same time the user is working on a new message in another window. Pieces of 
previous messages can be cut and pasted to reduce the work effort necessary 
and to ensure that all required information is included. A message generation 
window can be opened as an initial action at the beginning of a session or at 
any other time from the In-Box, filebox, or tickler. 

Once a message has been drafted, it must be approved by appropriate 
personnel in the chain-of-command before it can be released for transmission. 
This process is referred to as “chopping the message.” AMHS can assist in 
this process by electronically routing drafts to the accounts of those personnel 
that must chop the message. The message would appear in the user’s In-Box 
with an appropriate flag to designate it as a draft outgoing message. If the 
user approves the draft, it can be electronically chopped and forwarded up the 
chain-of-command. If rejected, it can be sent back to the originator. Electronic 
notes can be attached and routed along with the draft, and any cited refer- 
ences would be immediately available for review. These features will facili- 
tate the message approval process. 
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VI. CONCLUSIONS AND RECOMMENDATIONS 



The proposed design for the Automated Message Handling System 
(AMHS) illustrates how information technology can be used to improve the 
efficiency and effectiveness of current shipboard procedures. During the sys- 
tems analysis phase a relatively new technology, hypertext, was highlighted 
as the most promising alternative for enhancing user access to information 
while eliminating the need to distribute and store paper copies of messages. 
The mechanisms and features of hypertext offer exciting possibilities for 
automating the distribution, review, storage, retrieval and preparation of 
messages. Each of these processes is enhanced, eliminating many of the dis- 
advantages of the present paper system without sacrificing the benefits. 

A. BENEFITS OF HYPERTEXT 

Hypertext provides capabilities that can be used to revolutionize ship- 
board message handling procedures. The ability to electronically link infor- 
mation provides the opportunity to build a system where messages can be 
stored in electronic form without losing any of the advantages present in the 
current paper-based system. While maintaining only a single physical copy, 
each user is given the capability of treating the message as if it was his own 
personal copy. Distribution of information to users is accomplished by routing 
electronic links. This saves storage space, ensures message integrity and pro- 
vides increased access control. Messages can be annotated, highlighted and 
organized to reflect the individual views of users without requiring redundant 
storage or interfering with the views of others. The system provides access to 
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complete information by grouping related items, permitting users who want 
information on a particular topic area to access all messages, references and 
notes that are relevant without having to search each item individually. Use 
of such a technology enables the Navy to significantly improve the shipboard 
message handling process instead of simply duplicating the current system 
electronically. 

B. SUPPORT OF DESIGN PRINCIPLES 

Typically when a process is automated important questions arise con- 
cerning how the new system wall deal with existing policies and traditions. A 
set of principles and design issues was developed during the systems analysis 
phase to ensure that the AMHS design is compatible with Navy policies. 
These principles include maintaining the integrity and security of messages, 
ensuring quick and easy retrieval, controlling access, and providing flexibility 
and ease of use. Hypertext enables the proposed system to support each of 
these principles. 

C. RECOMMENDATIONS 

The result of adhering to these principles is a design for the AMHS that 
is consistent with the Navy’s current policies and trends to improve shipboard 
message handling procedures. The proposed system supports the objectives of 
the “paperless” ship initiative by reducing the requirements for paper aboard 
ship and making the information contained in message traffic more accessible 
and easier to use. The design for the AMHS can be readily adapted to fit on- 
going Navy automation efforts. AMHS is capable of filling the role of the 
office automation system described in the NAVMACS/PCMT plan to 
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modernize the communications center/user interface. Another alternative 
would be to develop AMHS as a direct interface between the users and the 
communications center. 

Advancements in computer technology make it feasible to implement the 
proposed system on currently available, low cost, commercial hardware. The 
prototyping efforts used during the design process support this point. The 
software technology necessary to develop AMHS is also available. While no 
single hypertext product offers all of the features identified during the analy- 
sis and design, the capability exists to build such a system using contempo- 
rary tools and techniques. 

Naval messages represent a vital shipboard information resource. The 
benefits offered by hypertext for improving the handling and use of this 
resource aboard ship make this technology worthy of further investigation. It 
is recommended that the logical design for the AMHS be rapidly prototyped 
to a more detailed level and tested aboard ship to determine its usefulness as 
an information management tool. 

The benefits of hypertext can be broadly applied to many shipboard 
automation efforts. This thesis has demonstrated that hypertext has potential 
for enhancing the usefulness of working materials. These items are especially 
important because they are used on a daily basis and represent the most 
current and up-to-date information available on the ship. While this paper 
has focused on messages, other materials that might benefit from further 
investigation include administrative files; personnel, training, and 
maintenance records; and stock and requisition reports. 
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The opportunity exists to use information technologies, such as hyper- 
text, to tie these currently separate pools of information together. The concept 
of electronically linking logically related items would enable users to have 
comprehensive access to information across such resources as messages, 
instructions, technical manuals and administrative files. The capability to 
access material in this manner would greatly improve the effectiveness of 
existing information assets. It is not necessary to design this as one all- 
encompassing system as long as a standard format is used in the development 
of the databases. Such an approach not only allows portions of the system to 
be built incrementally, but also increases the portability of the design to other 
hardware configurations. As systems are developed they can be tied to each 
other using the electronic links that characterize hypertext. 

Information is becoming an increasingly important resource in today’s 
Navy. Properly managed this resource can be a force multiplier to offset 
shortfalls in other areas, however in its current paper format it tends to 
create additional burdens on the personnel who must use and maintain it. 
Hypertext offers promising alternatives for improving user access to informa- 
tion which is stored in an electronic form. It is strongly recommended that the 
Navy investigate the potential for this technology to support the “paperless” 
ship initiative, taking a broad view of the application areas that might benefit 
from its use. 
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